3 ms·

No mention of ECDSA, although recent openssh, openssl, and many other crypto libraries support it. It's not usable for public facing SSL (few if any CAs will s

No mention of ECDSA, although recent openssh, openssl, and many other crypto libraries support it. It's not usable for public facing SSL (few if any CAs will sign an ECDSA csr), but it's eminently usable for ssh to servers that keep their openssh up to date (5.7 and later). http://www.nsa.gov/business/programs/elliptic_curve.shtml http://www.nsa.gov/business/programs/elliptic_curve.shtml "4096 bits is typically preferred..." by whom? Serious gpg/pgp users perhaps (all 1000 of them), but not most websites.[1] "...it is still feasible and doesn't 'break the bank' for CPU cycles on a modern server." Has the author bothered to benchmark 2048 bit rsa vs 4096 bit rsa? CPU time for signing goes from 2.5 or 5 ms (2048 bit), to 14 or 35ms (4096 bit), on two computers I just benchmarked (slower: xeon 5130 w/ openssl 1.0.0h, faster: i7-950 w/ openssl 1.0.1) [1] site: rsa key bits (default negotiated ciphersuite w/ openssl 1.0.0h) Google: 1024 bit (ECDHE-RSA-RC4-SHA -- nice) Facebook: 1024 bit (RC4-MD5) Twitter: 2048 bit (RC4-SHA) Linkedin: 2048 bit (RC4-MD5) Youtube: 1024 bit (ECDHE-RSA-RC4-SHA) Wikipedia: 2048 bit (RC4-SHA) Live.com: 2048 bit (AES128-SHA) Amazon: 10248 bit (RC4-MD5) Ebay: 2048 bit (RC4-SHA) USAA: 2048 bit (AES256-SHA) BofA: 2048 bit (RC4-MD5) Wells Fargo: 1024 bit (RC4-MD5) Citibank (online.): 2048 bit (AES256-SHA) TDAmeritrade: 1024 bit (RC4-MD5) Fidelity: 1024 bit (AES256-SHA) Etrade: 2048 bit (RC4-MD5) EFF: 2048 bit (DHE-RSA-AES256-SHA -- Someone knows what they're doing) EPIC: 2048 bit (DHE-RSA-AES256-SHA -- same)

tptacek 15y ago
In addition to the fact that lots of sites use RC4 TLS because it's faster, it's worth noting that DHE-RSA-AES256-SHA is a TLS 1.0 ciphersuite and was thus vulnerable to Thai and Juliano's blockwise-adaptive chosen plaintext attack. Several sites switched from AES to RC4 in advance of Thai and Juliano's publication. Using AES256 instead of AES128 doesn't make much of a practical difference (using 2048 bit keys, though, probably does). Also, more than one smart cryptographer has reservations with ECDSA (the one issue I'm aware of is that ECDSA/SHA-1 is especially vulnerable to collisions in SHA-1); there are replacement ECC signing algorithms in the literature now (EdDSA being one). ECDSA has also already had a couple major implementation errors (the one everyone thinks of is the nonce in Sony's implementation, but OpenSSL also coughed up private keys in a timing attack they've now fixed). I agree with your general point though, which is that this advise seems pretty arbitrary and not grounded in reality.

tptacek 15y ago

In addition to the fact that lots of sites use RC4 TLS because it's faster, it's worth noting that DHE-RSA-AES256-SHA is a TLS 1.0 ciphersuite and was thus vulnerable to Thai and Juliano's blockwise-adaptive chosen plaintext attack. Several sites switched from AES to RC4 in advance of Thai and Juliano's publication. Using AES256 instead of AES128 doesn't make much of a practical difference (using 2048 bit keys, though, probably does). Also, more than one smart cryptographer has reservations with ECDSA (the one issue I'm aware of is that ECDSA/SHA-1 is especially vulnerable to collisions in SHA-1); there are replacement ECC signing algorithms in the literature now (EdDSA being one). ECDSA has also already had a couple major implementation errors (the one everyone thinks of is the nonce in Sony's implementation, but OpenSSL also coughed up private keys in a timing attack they've now fixed). I agree with your general point though, which is that this advise seems pretty arbitrary and not grounded in reality.