Hacker News Reader

Comment by Wheaties466 | Hacker News Reader

How is the "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA38" cipher suite test "not used". Thats just BS, 22% performance is pretty big.

and 42% performance increase in TLS 1.3 handshakes is even bigger.

View on HN

I'd expect very few clients to negotiate using SHA-384. It's widely viewed as overkill compared to SHA-256, and it hurts performance.

I'm not saying it invalidates the benchmark results or anything—I just wanted to address your "not used" question.

Isn't SHA-256 vulnerable to length extension attacks?

Yes, but so is SHA-384 and that is not relevant for the TLS context.

384 is not vulnerable to length extension attacks precisely because it is truncated. The output is not he full internal state.

The speed advantage of SHA-512 and the advantage of truncation is why some more exotic variants like SHA-512/256 (SHA-512 truncated to 256 bits) are used in newer protocols.

SHA-384 can actually be faster than SHA-256 is some cases. The reason is that SHA-256 used 64 rounds with 32 bit words, while SHA-384 uses 80 rounds with 64 bit words. So, each block processed by SHA-384 is twice as big but uses less than twice as many rounds.

Oh yes, definitely. But SHA-384's output is 128 bits wider, which uses more bandwidth. Although for the AEAD ciphersuites, it doesn't make much of a difference, admittedly.

There is the not so widely used SHA-512/256 for that case - the speed of the 64 bit variants with a 256 bit output.

Reply on news.ycombinator.com