On Tue, 1 Apr 2014, Nikos Mavrogiannopoulos wrote:
This is wrong as you present it. You cannot substitute forward
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
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
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
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 /