Join Log in
Score:6
avatar Crypto

TLS 1.3 - Why have no encrypt-then-MAC modes been specified?

cn flag
Keith

I have been scratching my head for a while why TLS 1.3 does not include any encrypt-then-MAC (EtM) modes. All the previous problems in TLS have been caused by MAC then and encrypt. Whereas encrypt then MAC avoids all the issues caused by padding in the past since a receiver can verify the message integrity without having to first decrypt the message and then handle mangled padding correctly.

What is annoying about this to me is there are quite a few micro-controllers that have built-in AES hardware acceleration. However, something like a carry-less multiply for GCM really only exists on server and desktop CPUs.

While there is ChaCha20-Poly1305 using it instead means you forgo using AES hardware on micro-controllers. While ChaCha20 works well with 32bit micros it's still gonna use more power than built-in AES hardware and likely be slower depending on the micro. Also, Poly1305 requires doing some big-num modular arithmetic compared to a lot of hash functions.

I am just scratching my head since there is nothing wrong with EtM. I even found a draft IETF AES-CBC-HMAC where that performs EtM. However, it never made it past a draft which just strikes me as odd.

Edit: Since CCM Cipher suites were mentioned. while running AES in CTR mode does avoid padding oracles. It is not on of the mandatory cipher-suite or one of the SHOULD implement suites. See: Mandatory-to-Implement Cipher Suites So one basically can't take advantage of AES hardware on a micro without also having GCM. (i.g. lots of servers disable CCM by default and neither Firefox nor Chrome enable CCM). So again still seems odd there is nothing in-between here, and I don't really see any good reason why, and an EtM mode seems like a decent candidate, but one was never even added to the standard.

296
0 + 0
aes
tls
mac
Score:5
Maarten Bodewes avatar Crypto
in flag
Maarten Bodewes

For embedded devices there is CCM mode, which is basically a secure way of performing AES-CBC-MAC + AES-CTR in a (needlessly complex, but rather efficient) packet mode. Note that this is basically MAC-then-encrypt, but as part of an overall secure mode; padding oracles attacks are certainly not applicable as counter mode doesn't require padding.

The ciphersuites available are:

  • TLS_AES_128_CCM_SHA256
  • TLS_AES_128_CCM_8_SHA256 (as defined in RFC 6655)

The latter also has a more efficient authentication tag (with regards to size, not computational effort) of 8 bytes / 64 bits, which should be enough.

So I guess they didn't think that another algorithm is necessary, also because there are few embedded systems that have SHA-1 or SHA-256 acceleration.

Notes:

  • The hash at the end of the ciphersuite is only used for session key derivation and such (the PRF in TLS), so it isn't used for each message.
  • AES in CTR mode and in CBC-MAC is only used in the forward / encryption mode, so you don't need hardware support for the decryption operation.
0 + 0
kelalaka avatar
in flag
kelalaka
Is there a specific reason to write AES-CBC-MAC + AES-CTR instead of AES-CTR + AES-CBC-MAC other than indicating the MAC is performed before encryption?
0
Reply
Maarten Bodewes avatar
in flag
Maarten Bodewes
@kelalaka No, I thought it was less confusing this way.
2
Reply
kelalaka avatar
in flag
kelalaka
Maybe adding $$c = \big(\operatorname{AES-CTR}(m)\|(\operatorname{AES-CTR}(m_0) \oplus \operatorname{AES-CBC-MAC}\big(Nonce\mathbin\|Associated Data \mathbin\|m) \big)\big)$$ will make it more clear or unclear.
1
Reply
cn flag
Keith
Sure there is CCM. It's fine for instance if you control the server your device is talking to for like api request ect... One other thing that I have noticed though is other servers seem have it disabled often. Also chrome and firefox don't enable that cipher suite again limiting options.
0
Reply
cn flag
Keith
One other thing as you mention CCM is not EtM, but yes running AES basically as a stream cipher does avoid padding oracles. However, like I mentioned CCM modes of operation do not seem widely enabled. Basically, forcing something like ChaCha20-Poly1305 for wider compatibility since GCM is gonna require carry-less multiplies. It still just strikes me as odd since there is a gap here. Where as it seems like a some EtM mode would be more widely enabled, and just seems odd there are no EtM modes for TLS 1.3.
0
Reply
Maarten Bodewes avatar
in flag
Maarten Bodewes
Sure, but it is unclear how e.g. CBC + HMAC would fare as well. It would not likely be a required cipher suite, so it would be optional as well. That CCM is not EtM is kind of beside the point ... as long as it is secure. It is unlikely that somebody would implement it as decrypt, use and then verify - even if that's possible.
1
Reply
cn flag
Keith
Well CBC + HMAC is well a known construction, and if operated in an EtM construction avoids the main pitfalls of MAC of then encrypt. It does not seem unreasonable that even if it was optional that it would still be enabled more often since it's a well known construction.
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.