On Tue, 1 Apr 2014, Nikos Mavrogiannopoulos wrote:
This is wrong as you present it. You cannot substitute forward secrecy as a replacement for good parameters.
I did not intend to say anything like that and I am sorry if my choice of words was unfortunate enough to make such impression.
Much of the discussion dealt with RSA keys and their lengths. My point was that at a certain point it would become more efficient to invest man-hours and CPU cycles into stronger ephemeral DH (ECDH if possible) rather than into stronger server RSA keys.
A 512-bit DHE key exchange provides forward secrecy but does not provide secrecy.
This is an interesting example of the difference between "dictum simpliciter" and "dictum secundum quid". :)
On Tue, 1 Apr 2014, Hubert Kario wrote:
The ENISA recommendations are generic, not everybody uses ECDHE or DHE key exchange.
Indeed, the DH key exchange is optional when you use SSL/TLS. On the other hand, it is mandatory for IPsec or SSH (v2).
Also, cryptosystems that don't use primitives of comparable strength are rather frowned upon (if only because security assessment of such systems is more complex).
If we took that seriously, most TLS servers using 128+-bit symmetric keys should be frowned upon because their certification chains include RSA keys shorter than 3072 bits.
And even if the chain were strong enough, the whole TLS PKI would be only as strong as its weakest link and it is likely their clients trust root CA keys that are only 1024 bits long (C=US, O=Equifax, OU=Equifax Secure Certificate Authority and C=US, O=GTE Corporation, OU=GTE CyberTrust Solutions, Inc., CN=GTE CyberTrust Global Root to name two examples from tls-ca-bundle.pem in F20).
(This situation is, to be honest, ridiculous. Everything is completely upside-down. When you got a hierarchy of cryptographic keys, a key at its top should better be the strongest of all of them because if it were cracked the whole hierarchy would be compromised.)
-- Pavel Kankovsky aka Peak / Jeremiah 9:21 \ "For death is come up into our MS Windows(tm)..." \ 21st century edition / -- security mailing list security@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/security
