Live data from Hacker News

Overclocking SSL

imperialviolet.org

1–10 of 22 posts

Re: Overclocking SSL

#2
There are some server-side implementation notes here, focused on Apache: http://journal.paul.querna.org/articles/2010/07/10/overclock...

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.

Re: Overclocking SSL

#3
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.

Re: Overclocking SSL

#4
post #3

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 h…

That's an interesting point - as computers get faster at negotiating ssl ciphers, computers also get faster at breaking ssl ciphers.

I do hope that the factor on those two numbers is not the same though! So eventually one will win.

Re: Overclocking SSL

#5
post #3

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 h…

I don't know how cryptography works, so I'd like to know why the key length for all cryptography schemes seems to go up in powers of 2. What's the reason one couldn't have a 1300 bit RSA key, for example?

Re: Overclocking SSL

#6
post #3

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 h…

The article seems to contradict this: "An abbreviated handshake saves the server performing an RSA operation, but those are cheap anyway." Given that they are performing aggressive session caching, perhaps that 1% is mostly symmetric crypto.

Re: Overclocking SSL

#7
post #6
post #3

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 h…

The article seems to contradict this: "An abbreviated handshake saves the server performing an RSA operation, but those are cheap anyway." Given that they are performing aggressive session caching, perhaps that 1% is mostly symmetric crypto.

The problem is that even if you cache sessions, you still have to do the math to encrypt every packet. Encryption cost is a cube of key size. Please, contradict me. If you can, many cryptographers and mathematicians will thank you... :-)

Say what you will, but the difficulty of brute-forcing decryption is based on key length. You might be able to optimize the encryption using a certain length, but the key will still be vulnerable if it is only 1024 bit (as the article suggests).

Re: Overclocking SSL

#8
post #5
post #3

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 h…

I don't know how cryptography works, so I'd like to know why the key length for all cryptography schemes seems to go up in powers of 2. What's the reason one couldn't have a 1300 bit RSA key, for example?

I don't see any reason why you couldn't. It seems like a 1280 bit key should be secure for at least a few more years.

Re: Overclocking SSL

#9
post #7
post #6

Earlier quoted context omitted.

The article seems to contradict this: "An abbreviated handshake saves the server performing an RSA operation, but those are cheap anyway." Given that they are performing aggressive session caching, perhaps that 1% is mostly symmetric crypto.

The problem is that even if you cache sessions, you still have to do the math to encrypt every packet. Encryption cost is a cube of key size. Please, contradict me. If you can, many cryptographers and mathematicians will thank you... :-) Say what you will, but the difficulty of brute-forcing decryption is based on key length. You might be able to optimize the encryption using a certain length, but the key will still…

For SSL, aren't the individual packets encrypted with a symmetric cypher e.g. AES, RC4, 3DES, etc?

Re: Overclocking SSL

#10
post #3

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 h…

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

Post reply on HN