3 ms·

What are the motives for retaining the 1024 bit static dhparams? Wasn't it older Java that had trouble with larger dhparams? Nevertheless, couldn't this be mi

What are the motives for retaining the 1024 bit static dhparams? Wasn't it older Java that had trouble with larger dhparams? Nevertheless, couldn't this be mitigated somewhat by having openssl[1] dynamically generate dhparams? Isn't that what they do for ECDHE? 1024 bit DHE would still be crackable by the NSA, but with dynamic params it would take much longer since they wouldn't get to precompute anything. [1] Do schannel and other ssl implementations use static dh parameters by default, like openssl does, or do they dynamically generate them? And do they default to 1024 bit or are they smarter about it and default to match the RSA key size?

agwa 11y ago
Java, before version 8, couldn't handle DH parameters larger than 1024 bits, so that may be a motive. But I suspect a large part of it has to do with the fact that OpenSSL left DH parameter configuration (also ECDH curve selection) up to application developers, who don't really have the qualifications to make an intelligent choice. As a result, some applications make the administrator provide their own DH parameters file (and if you don't, no DH for you), others just hard code parameters (usually 1024 bits long, or 512 bits if the export flag is set) into their source code, and others dynamically generate them (and may or may not let you specify the length to generate). Unfortunately, this means that it's not a question of what OpenSSL can do to mitigate this, but what every single server application using OpenSSL has to do.
mmozeiko 11y ago
Generating dhparams every time is very expensive - it involves finding large prime which can take some time. ECDHE requires only to generate random N-bit number (any number) which is pretty much instant operation.
- tptacek 11y ago
  That's because with ECDHE you're accepting a much more extensive set of static parameters.
- agwa 11y ago
  You're conflating private keys and parameters. The random number that ECDH requires you to generate is the private key, just as FFDH requires you to generate a random private key (which is also fast). If you were actually generating your own random curves (which TLS doesn't allow) it would be much more expensive.

agwa 11y ago

Java, before version 8, couldn't handle DH parameters larger than 1024 bits, so that may be a motive. But I suspect a large part of it has to do with the fact that OpenSSL left DH parameter configuration (also ECDH curve selection) up to application developers, who don't really have the qualifications to make an intelligent choice. As a result, some applications make the administrator provide their own DH parameters file (and if you don't, no DH for you), others just hard code parameters (usually 1024 bits long, or 512 bits if the export flag is set) into their source code, and others dynamically generate them (and may or may not let you specify the length to generate). Unfortunately, this means that it's not a question of what OpenSSL can do to mitigate this, but what every single server application using OpenSSL has to do.

mmozeiko 11y ago

Generating dhparams every time is very expensive - it involves finding large prime which can take some time. ECDHE requires only to generate random N-bit number (any number) which is pretty much instant operation.

tptacek 11y ago
That's because with ECDHE you're accepting a much more extensive set of static parameters.
agwa 11y ago
You're conflating private keys and parameters. The random number that ECDH requires you to generate is the private key, just as FFDH requires you to generate a random private key (which is also fast). If you were actually generating your own random curves (which TLS doesn't allow) it would be much more expensive.