Overclocking SSL • Hacker News Board

Re: Overclocking SSL

#11

Post by caf » Sun, Oct 31, 2010, 5:00 AM UTC

lmz wrote: post #9

illumin8 wrote: post #7

Earlier quoted context omitted.

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?

Yes, the data stream is encrypted using a symmetric cipher, as the linked article says. The overhead of this is trivial.

It's the key exchange at the start of a session that requires the server to perform expensive RSA operations, which is why session caching helps.

Re: Overclocking SSL

#12

Post by WALoeIII » Sun, Oct 31, 2010, 5:40 AM UTC

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.

Re: Overclocking SSL

#13

Post by WALoeIII » Sun, Oct 31, 2010, 6:18 AM UTC

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

Why not?

Re: Overclocking SSL

#14

Post by john_nl » Sun, Oct 31, 2010, 6:27 AM UTC

spicyj wrote: post #10

illumin8 wrote: 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.

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.

Re: Overclocking SSL

#15

Post by js2 » Sun, Oct 31, 2010, 6:42 AM UTC

WALoeIII wrote: post #13

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

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

Re: Overclocking SSL

#16

Post by seabee » Sun, Oct 31, 2010, 8:50 AM UTC

ars wrote: post #4

illumin8 wrote: 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.

Would the codebreakers winning really be a better outcome than a constant arms race? :)

Re: Overclocking SSL

#17

Post by illumin8 » Sun, Oct 31, 2010, 12:16 PM UTC

spicyj wrote: post #10

illumin8 wrote: 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.

1024^3 = 1073741824 2048^3 = 8589934592 / 1024^3 = 8.

It depends on the implementation. Some implementations are more computationally expensive than others.

See: http://devcentral.f5.com/weblogs/macvittie/archive/2010/09/1...

Average of 5x reduction in transactions per second when moving from 1024 bit to 2048 bit keys.

Re: Overclocking SSL

#18

Post by illumin8 » Sun, Oct 31, 2010, 12:23 PM UTC

john_nl wrote: post #14

spicyj wrote: post #10

Earlier quoted context omitted.

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

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.

Cube, not square. Also, implementation matters.

2^3, or 8 times more expensive.

Re: Overclocking SSL

#19

Post by evgen » Sun, Oct 31, 2010, 5:08 PM UTC

binomial wrote: post #5

illumin8 wrote: 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?

Fast modmults for crypto keys are done using Montgomery multiplication, if the numbers being multiplied are power of two in size the ops are all masks and shifts after the initial transformation.

Re: Overclocking SSL

#20

Post by pmjordan » Sun, Oct 31, 2010, 7:48 PM UTC

ars wrote: post #4

illumin8 wrote: 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.

Complexity of breaking (presumably, prime factorisation in the case of RSA) is exponential wrt key size, whereas encryption has polynomial complexity. We'll be fine.