Hacker News new | ask | show | jobs
by tptacek 5450 days ago
RC4 is fine in SSL/TLS.

Nobody likes it, but until relatively recently, the AES ciphersuites were all CBC mode, which means they burned a couple bytes of padding for every record.

RC4 is also faster than AES, which was, until very recently, an issue for server performance.

We have AES-CTR ciphersuites now, but I'm not sure how widely deployed they are.

2 comments

The padding for AES cipher suites isn't a significant performance issue. The per-record IV in TLS 1.1 and later, the overhead of the tls-cbc.txt workaround for earlier versions, and/or the extra block(s) of encryption required for HMAC-SHA-2-based cipher suites are bigger performance issues.

RC4 is faster than AES on older processors. On the current generation of Intel server processors, AES is faster because of AES-NI.

AES-GCM cipher suites should be even faster yet on those processors, but they are not widely implemented. Also, I wouldn't be surprised to see more interesting papers being published about weaknesses in the GMAC function in the near future. (Note: I don't have any knowledge of upcoming papers; I am guessing there will be some based on the recent paper regarding the discovery of unexpected weak keys in GMAC.) Nonetheless, I suspect that NSS will implement them because they are part of the NSA Suite B profile for TLS and some NSS developers want a complete implementation of that.

I was under the impression that RC4-MD5 was no longer recommended but RC4-SHA was okay (comparatively). Is this incorrect?
The hash algorithm in TLS is HMAC-hash. Some uses of MD5 like secret suffix are now insecure (which is why usage of MD5 for certificate signing ended long ago), but HMAC is not one of them.