
A Reminder: Private Key Security - wglb
http://isc.sans.edu/diary.html?storyid=12817
======
tptacek
_Algorithm: RSA is usually providing the best tradeoff with respect to speed
and security, but for some applications, DSA may be more appropriate. Read up
on the particular application and find out what algorithm works best._

Jibber-jabber. Why doesn't he just say "we don't know", or, better yet, leave
this clause out?

------
harshreality
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>

"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
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.

