4 ms·

Really well written! One thing I was curious about was the use of TLS_RSA_WITH_RC4_128_MD5 instead of TLS_DHE_RSA_WITH_AES_256_CBC_SHA: what's the difference be

by edave 17y ago

Really well written! One thing I was curious about was the use of TLS_RSA_WITH_RC4_128_MD5 instead of TLS_DHE_RSA_WITH_AES_256_CBC_SHA: what's the difference between these setups in terms of mem/cpu usage? Obviously it varies between servers, but is it roughly 2x, 10x slower?

brl 17y ago
The relative cost of the symmetric bulk encryption algorithms (RC4 vs AES here) is irrelevant compared to the expense of the key exchange/agreement and authentication. The first ciphersuite uses the most common option where the server sends a certificate containing an RSA public key and the client chooses a random number, encrypts it with this key, and sends the encrypted value to the server. The server then decrypts this value with the private half of the key and derives the session keys from it. The expense of this decryption increases with the length of the RSA modulus. The second ciphersuite uses ephemeral diffie-hellman where both sides choose a random number, and then exchange them. In order to accomplish this securely, the server must at least provide a certificate with an RSA key that supports signing (and signature verification) so that the client can verify that the diffie-hellman parameter received from the server has not been tampered with. The DH parameter sent from the client to the server needs to be checked out too, and there are two ways this can be accomplished. If the server certificate contains a second RSA key which is marked as suitable for encryption, then the client can simply encrypt with this key as in the simple RSA key exchange described above. If this encryption key does not exist, then TLS provides a crazy way that the handshake can still succeed: 1) The server generates a temporary RSA key pair (very expensive) 2) The server signs the public half of the key pair with the RSA signing key in the certificate, and sends it to the client. 3) The client uses this key to encrypt the diffie-hellman value to send to the server. When the diffie-hellman parameters have been exchanged the server must perform an RSA private-key operation to either decrypt the client value or verify the signature on it. This has the same cost as in the first type of key exchange and depends again on the length of the RSA key. After verifying the client value, the server must complete the DH protocol which requires an expensive modular exponentiation which is roughly as expensive as an RSA operation. So no matter what, the second option is going to perform worse than the first option. The real reason though that the server probably rejected the second ciphersuite is because no certificate was available with an RSA signing key needed to complete the protocol.
- tptacek 17y ago
  Unfortunately, RC4 and AES are not comparably secure, and by conflating the cipher with the protocol variants, that issue is somewhat muddied by the article. Nobody should be using RC4. It's also a bit misleading to say that AES encrypts "16 bytes at a time" where RC4 encrypts 1 at a time: AES can easily be turned into a byte-at-a-time stream cipher using CTR mode; there's just not much value to doing so in TLS. There's another reason why DHE isn't super popular: inside enterprises, security groups will have reasons to want to monitor connections to their servers. DHE makes that pretty much impossible, by decoupling the server's private key from the actual session key. This sounds like a good thing until you realize that such monitoring has no privacy implications at all (they own the server, they can just sniff the sockets), only (negative) operational implications.
  - brl 17y ago
    > Nobody should be using RC4. I don't think this opinion gets enough play. A collision attack on SHA-1 is published which is still 'academic' enough that nobody has actually produced a single collision and Debian thinks it's worth re-keying their entire infrastructure over ("Attacks will only get better!"). Meanwhile, Fluhrer, Mantin, Shamir tore RC4 a new one almost a decade ago and everybody just applied a kludge and forgot about it. Then 5 years later, improved attacks are published and still no talk about permanently retiring RC4.
    - tptacek 17y ago
      I could be wrong but I think what's happening is this: RC4 is the only stream cipher anybody really knows. People don't really understand how OFB and CTR mode work, and don't get that AES is already a serviceable stream cipher. Therefore, people don't really have a "go-to" stream cipher besides RC4. You'd hope eSTREAM would change that --- Trivium would make a great replacement for RC4 --- but it may be that NIST simply has to bless something to make RC4 go away.
      - ajross 17y ago
        RC4 is also just plain beautiful; it's a permutation of all unique bytes with just two pointers into the array. It's implementable in what, 4 lines of code? Trivium is comparably simple, I guess, but the LFSR-like structure makes for significantly longer (and uglier, IMHO) code. Trivium is also brand new and has had vastly less attention paid to it. RC4 isn't "unbroken" exactly, but even after all these years RC4-based protocols are working securely in the real world right now, and that has to count for something. I'm not arguing for using RC4 either. The sentiment is more: "Don't diss RC4, it's still a really great piece of work."

by edave 17y ago

brl 17y ago

The relative cost of the symmetric bulk encryption algorithms (RC4 vs AES here) is irrelevant compared to the expense of the key exchange/agreement and authentication. The first ciphersuite uses the most common option where the server sends a certificate containing an RSA public key and the client chooses a random number, encrypts it with this key, and sends the encrypted value to the server. The server then decrypts this value with the private half of the key and derives the session keys from it. The expense of this decryption increases with the length of the RSA modulus. The second ciphersuite uses ephemeral diffie-hellman where both sides choose a random number, and then exchange them. In order to accomplish this securely, the server must at least provide a certificate with an RSA key that supports signing (and signature verification) so that the client can verify that the diffie-hellman parameter received from the server has not been tampered with. The DH parameter sent from the client to the server needs to be checked out too, and there are two ways this can be accomplished. If the server certificate contains a second RSA key which is marked as suitable for encryption, then the client can simply encrypt with this key as in the simple RSA key exchange described above. If this encryption key does not exist, then TLS provides a crazy way that the handshake can still succeed: 1) The server generates a temporary RSA key pair (very expensive) 2) The server signs the public half of the key pair with the RSA signing key in the certificate, and sends it to the client. 3) The client uses this key to encrypt the diffie-hellman value to send to the server. When the diffie-hellman parameters have been exchanged the server must perform an RSA private-key operation to either decrypt the client value or verify the signature on it. This has the same cost as in the first type of key exchange and depends again on the length of the RSA key. After verifying the client value, the server must complete the DH protocol which requires an expensive modular exponentiation which is roughly as expensive as an RSA operation. So no matter what, the second option is going to perform worse than the first option. The real reason though that the server probably rejected the second ciphersuite is because no certificate was available with an RSA signing key needed to complete the protocol.

tptacek 17y ago
Unfortunately, RC4 and AES are not comparably secure, and by conflating the cipher with the protocol variants, that issue is somewhat muddied by the article. Nobody should be using RC4. It's also a bit misleading to say that AES encrypts "16 bytes at a time" where RC4 encrypts 1 at a time: AES can easily be turned into a byte-at-a-time stream cipher using CTR mode; there's just not much value to doing so in TLS. There's another reason why DHE isn't super popular: inside enterprises, security groups will have reasons to want to monitor connections to their servers. DHE makes that pretty much impossible, by decoupling the server's private key from the actual session key. This sounds like a good thing until you realize that such monitoring has no privacy implications at all (they own the server, they can just sniff the sockets), only (negative) operational implications.
- brl 17y ago
  > Nobody should be using RC4. I don't think this opinion gets enough play. A collision attack on SHA-1 is published which is still 'academic' enough that nobody has actually produced a single collision and Debian thinks it's worth re-keying their entire infrastructure over ("Attacks will only get better!"). Meanwhile, Fluhrer, Mantin, Shamir tore RC4 a new one almost a decade ago and everybody just applied a kludge and forgot about it. Then 5 years later, improved attacks are published and still no talk about permanently retiring RC4.
  - tptacek 17y ago
    I could be wrong but I think what's happening is this: RC4 is the only stream cipher anybody really knows. People don't really understand how OFB and CTR mode work, and don't get that AES is already a serviceable stream cipher. Therefore, people don't really have a "go-to" stream cipher besides RC4. You'd hope eSTREAM would change that --- Trivium would make a great replacement for RC4 --- but it may be that NIST simply has to bless something to make RC4 go away.
    - ajross 17y ago
      RC4 is also just plain beautiful; it's a permutation of all unique bytes with just two pointers into the array. It's implementable in what, 4 lines of code? Trivium is comparably simple, I guess, but the LFSR-like structure makes for significantly longer (and uglier, IMHO) code. Trivium is also brand new and has had vastly less attention paid to it. RC4 isn't "unbroken" exactly, but even after all these years RC4-based protocols are working securely in the real world right now, and that has to count for something. I'm not arguing for using RC4 either. The sentiment is more: "Don't diss RC4, it's still a really great piece of work."