And what about SSH?

Posted May 22, 2015 14:59 UTC (Fri) by tialaramex (subscriber, #21167)
In reply to: And what about SSH? by cesarb
Parent article: Another crypto downgrade attack: Logjam

Yes, it is reasonable to think that a resourceful state actor _might_ have pre-computed answers for this popular modulus. This would allow them to passively eavesdrop SSH sessions using conventional DH with the affected settings, and also of course if they have complete transcripts, to play back older sessions using those settings. Likewise someone who cannot afford the work today, but does keep transcripts of encrypted sessions, will know that in the future they may be able to afford to decode them.

Regenerating the values should be done very carefully, or else not at all, since erroneous inputs destroy the security of DH entirely. Switching towards Elliptic Curves may be a better choice.

And what about SSH?

Posted May 22, 2015 21:04 UTC (Fri) by wahern (subscriber, #37304) [Link] (2 responses)

In retrospect we would have been better off randomly generating primes for DH rather than using fixed ones. Yes, you may generate a non-strong prime. But the likelihood is extraordinarily low as long as you generate what's called a safe prime. Fortunately, OpenSSL generates safe primes. (See crypto/dh/dh_gen.c.) It's why `openssl dhparam 1024` takes so much longer than `openssl genrsa 1024`.

In other words, just use OpenSSL to generate new DH parameters and move on to improving the rest of your software and infrastructure.

And what about SSH?

Posted May 24, 2015 9:35 UTC (Sun) by reubenhwk (guest, #75803) [Link] (1 responses)

generating a new DH* in OpenSSL can be very slow, especially 1024+ bits. It's not something you really want to do on startup. Better to read the p & g params from a file, then fork off a new process to generate new p & g in the background then write them out when done...

And what about SSH?

Posted May 27, 2015 17:40 UTC (Wed) by flussence (guest, #85566) [Link]

Something seems off here: `openssl dhparam 3072` takes 3-4 minutes for me on a fairly high end Intel server CPU, which is in line with what you said, but the gnutls equivalent `certtool --generate-dh-params --sec-param=high` takes 1-2 *seconds*.