[LINK] RFI: The Key-Length Currently Needed for SSL Security

[Scott Howard]

On Thu, Dec 9, 2010 at 1:58 PM, Roger Clarke <Roger.Clarke at xamax.com.au>wrote:

> [The article below suggests that the Chrome browser refuses to permit
> interactions with web-sites that use [presumably, symmetric] keys
> [presumably, for data encryption] shorter than 1024 bits.
>

The obvious thing they would be referring to here is the length of the
servers private key.  The standard minimum for these for years has been 1024
bits, although it's recently been bumped to 2048 bits.

However, the Citilink site - presuming they are referring to is
www.citylink.com.au - is using a 1024 bit private key, and given that the
key isn't a new one (dated 2008) it's unlikely that they changed it
recently...

TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 1024 bit


[If so, I wonder how many organisations can actually deploy
> sufficient computing power to crack 256-bit keys?  And how the cost
> of doing so compares with the benefits extractable from a single set
> of credit-card data?]
>

The reason for the change to minimum 2048 bit keys was on the basis that
within a 3 year period (ie, the maximum life of these keys) NIST predicted
that it would (may?) be possible to hack a 1024 key with generally available
computer power.  It's not expected that this it possible today - it's a
future-proofing thing.

  Scott