# What is wrong with AES-CTR-HMAC-SHA256 - or why is it not in TLS?

It seems the only specified CTR mode ciphers in TLS are all GCM based.

GCM ciphers run AES-CTR and do authenticated encryption with a MAC based on Galois-field arithmetic ("GHASH") - and the latter seems to be difficult to get right in software (side-channel attacks, constant time) or require CPU hardware support (e.g. Intel AES-NI / PCLMULQDQ) which in turn might be manipulated/weakened via microcode updates/implants.

On the other hand HMAC-SHA256 seems relatively simple to do right in software and when used together with AES-CTR and a encrypt-then-MAC scheme.

So why are there no modes like TLS_DHE_RSA_AES128_SHA256?

The closest I could find is this unfinished, expired IETF draft.

-
Perhaps because SHA256 is unacceptably slow - think 13 cycles/byte minimum (on top of the encryption cost). –  nightcracker Oct 27 '13 at 9:16
Well, AES-CBC-(HMAC)-SHA256 has that too, doesn't it? And SHA1 is less secure. And then you could have a AES-CTR-(HMAC)-SHA1 also. And the alternative of AEAD like AES-GCM is very new and not yet widely available. –  oberstet Oct 27 '13 at 10:55
I guess the reason may be both AES CTR and GMAC can be computed in parallel and as you state both can be hardware accelerated by many modern CPUs - not a drawback. In fact, the peak AES throughput with these instruction sets often can only be realised with at least 8 blocks computed at once to hide instruction latency. CTR-HMAC-SHA256 doesn't have the same performance characteristics (with either CTR or CBC it would be dominated by the HMAC processing time). So why add CTR-HMAC at all, it doesn't seem to add anything that GCM doesn't already do quicker. –  Stubabe Oct 27 '13 at 17:43
For reasons other than mere performance, e.g. simpler to get right in software without side-channel attack vectors. Also the principle cipher seems to be around longer than GCM. I am just wondering: why hasn't that RFC been finished years ago? –  oberstet Oct 28 '13 at 19:13
Well they had the opportunity to fix the MAC record format in TLS1.2 to remove the padding oracle completely (either by MACing the padding or moving to a EtA model), they didn't (which would be a far better solution in my view). Other than that I don't see your objection to CBC + HMAC as TLS1.1 onwards uses an explicit IV. –  Stubabe Oct 28 '13 at 20:58