Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

openwall.com

Post reply on HN
Print view View original

41–50 of 199 posts

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

#41

Post by duaneb »

phkahler wrote: post #34
swalsh wrote: post #17

I always wonder if when things like this get found, there's someone in the NSA going "Wow they finally found it, only took them x years"

>> I always wonder if when things like this get found, there's someone in the NSA going "Wow they finally found it, only took them x years" I would guess they were aware of the problem weather they created it or not. So yes.

> I would guess they were aware of the problem weather they created it or not.

While it's smart to assume so, it's also pretty laughable to think that the NSA has an exhaustive list of encryption vulnerabilities.

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

#42

Post by jcoffland »

baby wrote: 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 (…

The way this post is written it sounds like you are asking these questions but then you go on to answer them. It's confusing. It took me a second read to realize you are actually not calling the weakness in to question but explaining why it really is a weakness.

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

#43

Post by gcommer »

natch wrote: post #31

>there is no indication of how these parameters were chosen Is there really no protocol used in projects undertaken by the security community that would ensure that each component of the tools we rely on has a known history?

Well, socat has a git repo at git://repo.or.cz/socat.git so you can see the history of the prime number. In particular, it was upgraded from a 512 bit prime to a 1024 bit "prime" in commit 281d1bd on Jan 23, 2015.

Neither the code then, or the new code in this patch, have comments indicating how the prime was generated. (It is only mentioned in the advisory that openssl dhparams was used for the recent patch)

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

#45

Post by baby »

dzdt wrote: post #33
baby wrote: post #22

Earlier quoted context omitted.

if it's not an easy factorization => it will be hard. According to recent results we believe state-sized adversary should be able to do it. If you're threat model is against criminals, then you might be OK. EDIT: if 1024bits factorization is easy in general, you can say goodbye to every 1024bits RSA modulus. My first statement doesn't mean it can never be easy, it means that if you try and factor it the easy way and…

Well, it isn't known who provided the number in the first place. Whoever that unknown party is presumably knows the factorization they used to construct p. This could be a state, or could be a criminal enterprise. Better not to trust it!

Oh right. I guess I forgot this part 8)

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

#46

Post by baby »

jcoffland wrote: post #42
baby wrote: 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 (…

The way this post is written it sounds like you are asking these questions but then you go on to answer them. It's confusing. It took me a second read to realize you are actually not calling the weakness in to question but explaining why it really is a weakness.

edited to clarify :) thanks

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

#47

Post by jcoffland »

zitterbewegung wrote: post #18
openasocket wrote: post #12

Earlier quoted context omitted.

There are exact tests that run in polynomial time, like https://en.wikipedia.org/wiki/AKS_primality_test

Just because there are exact tests doesn't make the AKS primarily test usable in the real world because of constant factors . Using Fermats little theorem for primality testing is fine because the probably of encountering a Carmichael number is very low.

Seems like a Carmichael number could be a good choice for an attacker. This would make your chances of encountering a Carmichael number quite high. You have to consider who's choosing the number. Or do I have it wrong?

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

#48

Post by pbsd »

jcoffland wrote: post #47
zitterbewegung wrote: post #18

Earlier quoted context omitted.

Just because there are exact tests doesn't make the AKS primarily test usable in the real world because of constant factors . Using Fermats little theorem for primality testing is fine because the probably of encountering a Carmichael number is very low.

Seems like a Carmichael number could be a good choice for an attacker. This would make your chances of encountering a Carmichael number quite high. You have to consider who's choosing the number. Or do I have it wrong?

Only the simple Fermat tests are vulnerable to Carmichael numbers. The test which is used in practice, Rabin-Miller, is not vulnerable to them. In fact, if you assume the extended Riemann hypothesis is true, (log n)^2 iterations of Rabin-Miller are sufficient to prove primality.

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

#49

Post by matthewaveryusa »

mrb wrote: 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…

I'm pretty sure that when you generate a prime you're using the Miller–Rabin primality test in which case you only probabilistically choose a prime.

In fact, the is_prime functions in openssl don't check if a number is prime. They only check that a number is prime within 1-2^-80 probability. I'm not sure what the implications are though.

See https://www.openssl.org/docs/manmaster/crypto/BN_generate_pr...

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

#50

Post by yeukhon »

LukeShu wrote: post #20
yeukhon wrote: post #8

Earlier quoted context omitted.

I think the first line is confusing and misleading until I read yours. > In the OpenSSL address implementation the hard coded 1024 bit DH p parameter was not prime. It should have been worded "In Socat, the DH p parameter used by OpenSSL implementation was hardcoded and was not a prime."

The original phrasing is correct, but confusing if you aren't familiar with socat. Socat fundamentally works by giving it a pair of addresses; they are referring to socat's implementation of addresses starting with "OPENSSL:" (caps-insensitive), AKA "OpenSSL addresses".

I see. You are right, and yes I may have jumped to the gun too quickly.
Post reply on HN