Socat: “the hard coded 1024 bit DH p parameter was not prime”
1–10 of 199 posts
Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”
#2That looks like it's for 'socat', not openssl itself ...
Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”
#3Title is misleading -- this appears to be an issue with a tool called socat, not with OpenSSL. That's a world of a difference in the severity of the issue.
Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”
#4This 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).
Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”
#5Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”
#6This 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).
"Footgun API" - I like that!
Its an interesting challenge though, I wonder if the person who picked the constant the first time understood the ramifications of it being prime or not. And if they did, how hard they worked to validate its primality.
Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”
#7Title is misleading -- this appears to be an issue with a tool called socat, not with OpenSSL. That's a world of a difference in the severity of the issue.
Thanks, I fixed the title. (For the record it was "OpenSSL: the hard coded 1024 bit DH p parameter was not prime").
Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”
#8Title is misleading -- this appears to be an issue with a tool called socat, not with OpenSSL. That's a world of a difference in the severity of the issue.
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."
Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”
#9Q: 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 (Zp)* is the euler's totient function on p. If you know the order of the multiplicative group then you have an algorithm to find the order of your generator: you try all the divisors of the group's order, see the smallest one that works.
Unfortunately, if you don't know how to factor p then you can't easily do that.
Another question is: How can they know it's not a prime if they don't know the factorization of p? We have efficient provable tests for that: they tell you if p is prime or not and nothing else.
Re: Socat: “the hard coded 1024 bit DH p parameter was not prime”
#10Q: 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 (…
> We have efficient provable tests for that: they tell you if p is prime or not and nothing else.
I think this is a typo -- the efficient general-form tests are probable rather than provable.
https://en.wikipedia.org/wiki/Primality_test#Probabilistic_t...