
Overclocking SSL - n-named
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
======
illumin8
The article states that SSL encrypted with a 1024 bit RSA key is
computationally inexpensive, taking less than 1% of the CPU time on his
current web servers. This is correct, however, 1024 bit RSA is no longer
considered secure enough. It can be brute forced by modern computing systems.

In fact, the NIST has recommended that all SSL systems be upgraded to 2048 bit
keys by January 1st, 2011. This recommendation will have "teeth" for financial
institutions that must comply with PCI guidelines, and healthcare that must
comply with HIPPA, ARRA, and HITECH regulations.

The problem is that encryption with larger key sizes is computationally much
more than 2x expensive. In fact, compute costs are based on a cube of key
size, meaning encryption using a 2048 bit private key can be as much as 30x
more expensive than 1024 bit.

I agree that website operators should encrypt everywhere, however, encryption
with weak keys might be almost as bad as no encryption in the near future, by
giving people a false sense of security.

If you are running a serious volume website, you pretty much need SSL
accelerators to handle the volume of traffic with 2048 bit encryption. 1-2%
CPU load on your web servers can be managed, but 30-60% cannot.

~~~
spicyj
> The problem is that encryption with larger key sizes is computationally much
> more than 2x expensive. In fact, compute costs are based on a cube of key
> size, meaning encryption using a 2048 bit private key can be as much as 30x
> more expensive than 1024 bit.

How'd you get 30? From what you said, it sounds like it should be 2^3 = 8
times as expensive.

~~~
john_nl
I'm also curious where the 30x comes from. If cost is indeed the square of key
size I would expect:

    
    
      Cost(1024) = (1024*x)^2
      Cost(2048) = (2048*x)^2 = (2*1024*x)^2 = 4 * (1024*x)^2
    

Which is a 4x increase in cost, not 30x.

~~~
illumin8
Cube, not square. Also, implementation matters.

2^3, or 8 times more expensive.

------
ivank
There are some server-side implementation notes here, focused on Apache:
[http://journal.paul.querna.org/articles/2010/07/10/overclock...](http://journal.paul.querna.org/articles/2010/07/10/overclocking-
mod_ssl/)

<http://www.imperialviolet.org/2010/09/05/blacklisting.html> is also
interesting; it says Chrome will use a blacklist to avoid using False Start on
some domains.

Also, does anyone know which older clients require that the server cache the
session information? The article doesn't say.

------
WALoeIII
Does the extra 1K added by OSCP stapling put enough pressure to make your
payload too big for the initial TCP window? It seems like it is impossible to
use a 2048 bit key, include an intermediate certificate and turn on OSCP
stapling while staying under 4k.

------
thefreshteapot
Interesting article, lead me on a bit of a side tangent to my usual monday
morning.

Based on people saying that 1024 bit RSA is no longer considered secure. I
hunted down what I believe is at least one source from nist.gov.

[http://www.nist.gov/manuscript-publication-
search.cfm?pub_id...](http://www.nist.gov/manuscript-publication-
search.cfm?pub_id=903633)

With the default having to be increased in less than a few months, I was a
little surprised to see that google, having recently trumpeted about their
"encrypted" search is using 1024bits.

<https://encrypted.google.com/>

If you check their certificates you will see it is 1024bit.

I was hoping to compare it to <https://duckduckgo.com>, yet it turns out they
too are running 1024bits.

I hasten to add, I dont really understand the significance of different
ciphers used etc, this is purely based on bits.

~~~
eru
Elliptic curve cryptography can get away with less bits in the keys than RSA
at the moment. We do a better job of breaking RSA than elliptic curves. I
don't know about Diffie-Hellman, which is based on discrete logarithms.

------
WALoeIII
Can someone explain this statement: "remember that there's no point using
AES-256 with a 1024-bit public key"

Why not?

~~~
js2
Because once the 1024-bit RSA is cracked, it doesn't matter how strong the
symmetric algorithm is as you'll have its key. Analogy: a virtually
uncrackable safe (AES-256) whose combination is written on a piece of paper
that's stuck in a box protected by a weak padlock (1024-bit RSA).

