Live data from Hacker News

Socat: “the hard coded 1024 bit DH p parameter was not prime”

openwall.com

131–140 of 199 posts

Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”

#131

Earlier quoted context omitted.

Aren't large non-primes usually created by multiplying two large but smaller primes together. Factoring is then the challenge. Or is there more to this that I'm missing?

The question is whether they: a) knew it was non-prime, and used it to weaken the crypto b) knew it was non-prime, and used it because they didn't think it needed to be prime (which is a massive sin of ignorance) c) grabbed 1024 bits of rand() and didn't check if it was prime (again, stupid) d) grabbed some rand and checked the prime-ness using a bad method e) used a "prime number generator" that produced bad output…

f) Used a machine with bad RAM that flipped a bit.

This case could actually be tested for - see if any of the one-bit differences from the number used are prime.

Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”

#132
post #126

Earlier quoted context omitted.

Pi would be a good source, but they are in the wrong order.

Pi would be a horrible source. Why would you want to use a deterministic digit generation function to generate your entropy. Even if you always used very large digit offsets. I can't imagine it being a remotely good idea.

As a source of primes? OP never said he wanted them to be random, and pi does contain every (finite) number. :P

Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”

#133
post #86
post #80

Earlier quoted context omitted.

> 2^-80 is an incomprehensibly tiny number. When one wants a 128-bit security margin, 2^-80 is 2^48 times too big.

This is not a valid comparison. An attacker who can bruteforce, say, 2^80 128-bit keys (approximate limit of the computational power of the largest adversaries) has 1 chance out of 2^48 to break the security. But an attacker has only 1 chance out of 2^80 that this parameter is a non-prime. 2^80 is much larger than 2^48, therefore it is not a problem.

It's not about bruteforcing.

If I want a 128-bit security level, I'm willing for a random guess of my key to have a 2^-128 chance of being correct. I'm likewise willing for a prime I generate to have a 2^-128/uses chance of not being prime (where uses is equal to the number of times I'll actually be using it).

I can't be 100% certain that a large number is actually prime. But I can be certain enough. Having a 2^-80 chance of being wrong isn't good enough when I want a 2^-128 security level.

Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”

#134
post #80

Earlier quoted context omitted.

> 2^-80 is an incomprehensibly tiny number. When one wants a 128-bit security margin, 2^-80 is 2^48 times too big.

Apples and oranges. When we talk about 128-bit security, we mean that it takes ~2^128 work to break it; not that there's a 2^-128 chance that it is broken.

> When we talk about 128-bit security, we mean that it takes ~2^128 work to break it; not that there's a 2^-128 chance that it is broken.

But it also implies that e.g. the attacker has a 2^-128 chance of randomly guessing a key.

Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”

#135
Very nice asymmetric backdoor!

If you happen to know the factorization and the factors are not too large (e.g. two 500-bit factors + some chaff), then you can just use Pohlig-Hellman algorithm to solve the DLP modulo each individual factor, combine the results and recover the shared Diffie-Hellman secret.

But without this trapdoor information (and, say, if p was chosen to be a Blum integer), computing the Diffie-Hellman shared secret is as hard as factoring that modulus (see https://crypto.stanford.edu/~dabo/abstracts/DHfact.html).

Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”

#137
post #55

Earlier quoted context omitted.

2^-80 is an incomprehensibly tiny number. Malice or incompetence are both FAR more likely.

You know, I never know what to make of that logic - what if that tiny probability was exactly this one time? It's not like we saw it happen twice, and it could happen at some point. To my gut it seems you can't really know until you have other positive or negative observations. I wonder if someone has compiled a list of very improbable events that have been observed.

Wow - this has got to be my most downvoted comment. I can't edit the original anymore, so here's my update:

I guess the harsh reaction came from the fact that I didn't define the scope very well: My question wasn't in reference to M-R specifically, just in general. I understand that in this case it makes sense to look at likelier causes (see Sharlin's response).

My point was that it's interesting to look at what happens (or what our reaction is) when very very very improbable events do happen. It seems weird to go with the assumption that because something is extremely unlikely that it won't happen.

When I roll a dice 20 times, I get a particular arrangement of numbers. Given the total number of arrangements possible, that particular arrangement is extremely unlikely, yet I just got it.

A guy got struck by lightning 7 times (https://en.wikipedia.org/wiki/Roy_Sullivan). The odds of any person getting struck by lightning is 1 in 10000. Seven times in a row is 1 in 2^93. But then when you start drilling down, you see that he's a park ranger, and that he's out while lightning happens, which makes the probability that he'll get struck much higher.

If I had phrased the question to you asking what the likelihood of any given person in the world being struck seven times was, you could have calculated the former and said 2^-93 is such a small probability that it's not worth thinking about - and yet here is Roy Sullivan, so there's some sort of conflict in my logic. What's wrong with the former calculation?

Why is it that for any given person the probability is 2^-93 but for Roy it's somehow different, even though he is a "given person"? Is it that the 1 in 10000 number was wrong? But then if we look at all the people who never once got struck, it seems about right. If we inflate that number to 1 in 100 to make Roy likelier to get 7 in a row, then it seems everyone also should be getting shocked more often at least once or twice.

Or maybe it's that somehow the probability changes when we have more information and those two numbers and situations are not comparable on an absolute scale. Maybe if you get hit twice then you're much likelier to get hit again because you're probably in some dangerous location - but how was I to know to factor this in? It seems that it's very much about how you calculate the probability. Who knows what other hidden factors could be wildly affecting the true value of the probability?

That also makes me think - is there even such a thing as the "true" or inherent probability of an event happening?

edit: Or maybe it's the law of large numbers - given enough "trials" or in this case lightning events with people around, even something with an absurdly small probability is bound to happen eventually. But then why do we never factor that in and always just call it a day with 10000^7?

Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”

#138
post #133
post #86

Earlier quoted context omitted.

This is not a valid comparison. An attacker who can bruteforce, say, 2^80 128-bit keys (approximate limit of the computational power of the largest adversaries) has 1 chance out of 2^48 to break the security. But an attacker has only 1 chance out of 2^80 that this parameter is a non-prime. 2^80 is much larger than 2^48, therefore it is not a problem.

It's not about bruteforcing. If I want a 128-bit security level, I'm willing for a random guess of my key to have a 2^-128 chance of being correct. I'm likewise willing for a prime I generate to have a 2^-128/uses chance of not being prime (where uses is equal to the number of times I'll actually be using it). I can't be 100% certain that a large number is actually prime. But I can be certain enough . Having a 2^-80…

Yes, security margins are all about what can and cannot be brute forced!

You can't compare these 2 scenarios directly, because in practice:

- attackers can take as many guesses as they want against a piece of data protected by a 128-bit key, but

- attackers get only 1 chance that a particular piece of data protected by a supposed prime is not a prime.

Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”

#139
post #82
post #14

Earlier quoted context omitted.

p not being prime means it has not been generated using a standard tool like OpenSSL. It's therefore likely it's been handcrafted for nefarious purposes, opening the possibility of further shenanigans. Another possibility would be the use of a buggy generator, or a clueless dev using random bits rather than a large prime.

Or someone made a mistake copying and pasting. Edit: wow. that is serendipity. Just accidentally posted twice. Does hitting "submit" twice do that?

> Edit: wow. that is serendipity. Just accidentally posted twice. Does hitting "submit" twice do that?

I get that a lot. I've not worked out what's causing it.

Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”

#140
post #89

Earlier quoted context omitted.

That's a nice piece of plausible deniability, huh? I wonder if the committer has a few extra bytes that he can claim were supposed to be there which make a number that passes all the primality tests? That'd be a nice excuse for the NSA/3PLA overlords to have given him...

Extra bytes would have made it not a 1024-bit integer.

Whicgh provides an excuse for why the prime was truncated, and OOPS made it into a not-prime.
Post reply on HN