[Cryptography] DH non-prime kills "socat" command security

Peter Gutmann pgut001 at cs.auckland.ac.nz
Fri Feb 5 21:38:21 EST 2016


mok-kong shen <mok-kong.shen at t-online.de> writes:

>Among possible causes I surmise that possibly Miller-Rabin test was used to
>find a prime,

I doubt it.  I surmise that possibly Google was used to find it, and then you
cut & paste what's in the first search result on Stackexchange.

(As Leif Johansson added in commentary:

   https://twitter.com/stackexchange/status/623139544276299776).

It really is that bad, the amount of crappy code that gets propagated through
there is scary: people have a problem they can't easily solve, Google leads
them to Stackexchange where others have had the same problem, they grab the
code there, done.

Alternatively, it could have been 128 bytes from /dev/random.  "FIPS 140 needs
a random number of size X, this is a random number of size X":
 
https://www.google.co.nz/search?q=%E2%80%9Cstring+to+make+the+random+number+generator+think+it+has+entropy%E2%80%9D

(The response to the above from someone on another mailing list was an
apropos:

  I think my soul just got a few more scars and dark spots).

In any case though people still seem to be missing the big picture, that
despite the non-prime being just that, it was still a lot more secure than the
512-bit value that it replaced.  The 1024-bit value has as its largest factor
a 1002-bit value that, while also being non-prime, isn't easily factorisable.
That's still better than the 512-bit (alleged) prime that it replaced:

http://repo.or.cz/socat.git/commitdiff/281d1bd6515c2f0f8984fc168fb3d3b91c20bdc0

(Has anyone checked the earlier value?  I don't have PARI/GP on here so I
can't check it right now).

So it's quite possible that moving to the 1024-bit non-prime was an increase
in security over the previous state of the code.

Peter.


More information about the cryptography mailing list