Live data from Hacker News

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

openwall.com

151–160 of 199 posts

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

#151

Earlier quoted context omitted.

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 happ…

> 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"?

Because it isn't true that the probability of any given person being struck by lightning is 1/10000. For instance, the internet says that men are around 4 times as likely to be struck by lightning as women. Rather, what's true is that the likelihood of a randomly selected person being struck by lightning is 1/10000. Each individual person has a different likelihood to be struck. I don't know how to calculate it for Roy, but given that he's been struck 7 times I'm sure it's way higher than 1/10000.

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

I love when people email me after reaching an enlightenment.

There was a probability question that drove me nuts until I figured out what was going on. The question is "A woman has two children. One of her children is a boy. What is the probability that she has two boys?".

The question isn't well defined, because it matters how you learned that one of her children is a boy.

If you asked her "what is the gender of your oldest child?", and she says it's a boy, then the probability that she has two boys is 1/2.

But if you asked her "do you have at least one boy?", and she says yes, then the probability that she has two boys is 1/3.

I don't know what the lesson here is. Probability is hard? Always ask about the experiment?

> is there even such a thing as the "true" or inherent probability of an event happening?

The probability of something depends on what you know. What's the chance that Roy will be struck by lightning tomorrow? If you don't know who Roy is, you might say 1/(10000 * 28000) (where 28000 days is the average human lifespan.). If you do know Roy's history, you'll probably bump that estimate up quite a bit. But if you look up the weather in his park tomorrow and see that it will be sunny all day, the probability will go back down close to zero.

Some things are so hard to know they might as well have an inherent probability, though. If you roll a die, no one's going to predict the outcome of the roll, so we might as well say it's inherently got a 1/6 chance of rolling a 5. And if you shine a photon at a half-silvered mirror, it's actually impossible to predict which way it will go, so I guess that really does have in inherent probability.

You've got to watch out for your probability estimates being wrong, though. I thought the probability of my friend flipping a coin and getting heads was 1/2, until he demonstrated that he could flip heads 10 times in a row.

> 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?

Because even with 10 billion people, each living a billion days, and having a billion things happen to them in a day... well coincidentally that's exactly 10^28=10000^7, so never mind.

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

#152
post #9

Q: How does p not being a prime => backdoor? A: p not being a prime means two things: * subgroup confinement attacks (where you send a public key made with a fake generator g) should be able to take place if the code is weak -> this is because there must be low order subgroups. * the generator g might not be of great order. This can be easily tested if you know how to factor p: the order of the multiplicative group (…

Some of these issues are orthogonal.

You're correct that the ring of integers mod n with n composite will have small multiplicative subgroups. But so will the integers mod p with p prime. At the very least, 1 and p-1 will always have orders 1 and 2, respectively. I could be wrong, but I don't think the primality or compositeness of the modulus alone tells you much about the smoothness of the group order.

Small subgroups may not always lead to key recovery, but they can lead to key dictation in certain protocols. So subgroup-confinement attacks are always a consideration in this setting.

If you want to learn more about subgroup-confinement attacks on DH and ECDH, check out set 8 of cryptopals. Mail set8.cryptopals@gmail.com with subject "Crazy Flamboyant for the Rap Enjoyment".

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

#154
post #126

Earlier quoted context omitted.

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

That is not know to be the case, only conjectured.

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

#155
It's interesting that all the time no one noticed it was not actually prime. This leans skepticism towards assumptions that widely used security critical open source code is reviewed by anyone competent at evaluating it, even over long periods of time.

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

#156
post #37

It irks me that in security advisories that fix a possible backdoor—like here—sometimes no root cause analysis is done or communicated to the public. Who chose this parameter? Who wrote the code? Who committed it? So I did a little sleuthing... Here is the commit introducing the non-prime parameter (committed by Gerhard Rieger who is the same socat developer who fixed the issue today): http://repo.or.cz/socat.git/com…

> Here is a message he wrote

In that Zhigang explicitly states that "I don't have enough knowledge to implement the merge." Yet the code is accepted without the slightest review whatsoever.

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

#157
post #4

This is a vulnerability in socat's TLS support. It has nothing to do with OpenSSL (besides the fact that OpenSSL provided a footgun API by leaving it to application developers to supply DH parameters).

btw, they recommend checking custom params via DH_check() (https://wiki.openssl.org/index.php/Diffie-Hellman_parameters...) but, appparently, neither apache nor nginx do this...

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

#158
post #154

Earlier quoted context omitted.

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

That is not know to be the case, only conjectured.

I thought it was proven to be trancendental? Or were you saying that this property of trancendental numbers is only conjectured?

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

#159

Earlier quoted context omitted.

The optional comma at the end of the list of entries in an array is explicitly allowed by the C standard.

(Actually I may be confusing the extra comma here with an extra comma at the end of an enum list. Some compilers are OK with that, while others aren't.)

If I'm reading N1256 right (not sure how far back it actually dates, but that's a C standard draft dated 2007), section 6.7.2.3 also explicitly allows a trailing comma in that context as well, so if such a compiler exists its makers should get with the program, so to speak.

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

#160
post #99
post #55

Earlier quoted context omitted.

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

Assuming you are given a single number and you test it and is_prime says it is prime. If on the other hand you are looking for a number that is_prime says is prime, and you are iterating through candidates, you need to know how likely it is to find a prime number in the first place to tell you how unlikely this is. In most cases the chance of a false positive will be much, much higher than 2^-80. If for example, you…

[deleted]
Post reply on HN