1
$\begingroup$

A couple years ago, I devised some primitives for block ciphers and block cipher modes of operation; I was partly inspired by CAESAR. What these designs all had in common is that the encryption/decryption process would produce a bit string $T_i$ for each block and all of these bit strings would be combined together to make the authentication tag $T$.

Today I remembered some of the reasons why encrypt-then-MAC is preferred over other authentication methods, so now I'd like to know if the authenticated encryption schene described above is undesirable.

$\endgroup$

1 Answer 1

1
$\begingroup$

That sounds like OCB. OCB and similar schemes are fine. Security bounds are usually a little weaker than non-integrated Encrypt then MAC(EtM) constructions but not enough to matter.

But creating your own? OCB-like constructions are subtle and can break very very badly. OCB2 was shown to be completely insecure for example. EtM constructions are pretty easy to get right. If building your own EtM construction is like cutting down a tree, creating an OCB-like construction would be juggling running chainsaws.

Side channel attacks

If side channel attacks are a concern, then EtM constructions help in that decryption keys are never touched until the authentication tag is checked. If the attacker is mounting a side channel attack to recover the encryption keys that adds an additional inconvenience (need to recover the MAC key first).

$\endgroup$
2
  • $\begingroup$ Note that OCB and current standardised/popular schemes (e.g. AES-GCM, ChaCha20-Poly1305) have a design flaw in that they're not committing. This causes vulnerabilities in certain scenarios like for messaging apps. Sponge-based constructions are a simple fix for this problem assuming they have a large enough tag, like AEGIS. Encrypt-then-MAC done properly also solves this problem. $\endgroup$ Commented Jun 15, 2023 at 11:35
  • $\begingroup$ I don't know if it's OCB-like or not. I'm pretty sure it's more general than OCB. What I mean is is it undesirable for the same reasons MAC-then-encrypt or encrypt-and-MAC are? Like, how the decrypted data is vulnerable to handling without authentication. $\endgroup$
    – Melab
    Commented Jun 22, 2023 at 15:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.