[tuxxy]

There's nothing error prone about choosing to do Encrypt-then-MAC, but there could be some issues with how they implemented AES-CTR.

Plain and simple, there is just more room to make a grave mistake.

[dom0]

I'll assume that restic does not actually implement AES. I maintain that rolling EtM is effectively not more error prone than correctly using a dedicated AEAD construction, since in either case you are rolling your own crypto, which swamps error proneness differences between these alternatives.

[tptacek]

I'm not sure I follow this. A library implementation of an AEAD, with "Seal" and "Unseal" functions, is almost misuse-resistant (depending on the primitive and how they handle nonces). The same is not true of a library that exports AES-CTR or AES-CBC's Encrypt/Decrypt, plus a MAC!

If you're implementing an entire AEAD construction, like GCM or EAX, from scratch, then yes. Don't do that. You probably are safer composing CBC and HMAC than you would be writing your own EAX.

But if your library exports an EAX, using it is almost certainly a huge security win over DIY authenticated encryption, even if you can remember the order of operations properly.

[tedunangst]

Well, in comparison, there are plenty of opportunities for grave mistakes with AES-GCM.

[azinman2]

Pointers?

[wolf550e]

Nonce reuse

[azinman2]

Isn’t that a gotcha for anytime you’d use a nonce?

Meanwhile PubNub is using a hard coded IV on every message in ECB and CBC modes :)

https://github.com/pubnub/javascript/blob/master/src/core/co...

[kaoD]

Well that's a gotcha on AES-CTR too.

GP is asking about mistakes that could happen on AES-GCM that won't happen with AES-CTR+HMAC.

I'm no crypto expert, but I'd say there are more opportunities of messing up with AES-CTR+HMAC like forgetting to MAC the IV.

[tedunangst]

Nonce reuse for CTR gives you the plaintext of those messages. (Well, the XOR of them, from which you can probably figure out the rest.) Nonce reuse for GCM gives up the key.