5
$\begingroup$

As most know, a duplicate nonce with GMAC/GCM allows key recovery attacks against GMAC itself and thus the ability to forge messages. This is because GMAC computes GHASH and then just XORs this with AES(j) where j is the GCM counter. If a nonce is duplicate you get identical AES(j) which lets you XOR and get the raw GHASH and then attack the GCM polynomial.

Why doesn't GCM encrypt its final authentication tag using AES in ECB mode (one ECB block)? If performance is a concern and you want to avoid doing two AES encryptions why not do AES(GHASH(m) ^ j) or similar? GHASH(m) XOR AES(j) seems like it's begging for sudden death on nonce reuse. Why do that?

It seems like this simple design change would have made GCM/GMAC more resistant to nonce repetition. You'd still be able to XOR ciphertexts just like you can with any stream cipher when a nonce is repeated but you wouldn't be able to compromise the authentication key, right?

Improve this question
$\endgroup$
8
  • 2
    $\begingroup$ Maybe it is because reusing the same (edit: keyed) symmetric cipher for two different purposes may create unforeseen issues during correct usage, e.g. when the input of the MAC value is identical to a previous input. $\endgroup$
    – Maarten Bodewes ♦
    Sep 4, 2019 at 14:40
  • 1
    $\begingroup$ Could be that they're playing it safe. Could also be that the security proof would become more complicated otherwise, you would have one more thing to proof after all. $\endgroup$
    – Maarten Bodewes ♦
    Sep 4, 2019 at 15:03
  • 1
    $\begingroup$ There's little point in this because all is lost anyways on nonce reuse (namely the CTR encryption leaks plaintext XORs), so might as well make the best out of the situation, also if we would encrypt it would no longer be a Carter-Wegman MAC. $\endgroup$
    – SEJPM
    Sep 4, 2019 at 17:27
  • 2
    $\begingroup$ The standard security notion for an authenticated cipher considers an adversary to win if the adversary forges a message or distinguishes messages. It's not terribly helpful to provide a primitive that prevents only one or the other but not both. $\endgroup$
    – Squeamish Ossifrage
    Sep 5, 2019 at 3:14
  • 1
    $\begingroup$ @SEJPM Why does it matter whether it's a Carter–Wegman MAC or not? (Essentially AES-GCM does encrypt the message hash with a one-time pad generated by AES, rather than encrypting the message hash by feeding it through AES as Adam suggests.) $\endgroup$
    – Squeamish Ossifrage
    Sep 5, 2019 at 3:16

1 Answer 1

Reset to default
6
$\begingroup$

Latency, probably.

$\mathrm{GHASH}_K(m) \oplus \mathrm{AES}_K(n)$ lets you compute both in parallel, whereas encrypting the $\mathrm{GHASH}$ output would add significant latency for short messages. The authors go to great detail about this in Section 3 of the original GCM document.

A similar competing mode at the time, CWC, did indeed encrypt the MAC output but was not as efficient.

Improve this answer
$\endgroup$
1
  • 3
    $\begingroup$ It is most certainly latency. GCM was originally designed to be run in a pipelined AES implementation; encrypting the tag would require another pass through the AES chain (which means that the tag wouldn't be available until 10 cycles after the rest of the message) $\endgroup$
    – poncho
    Sep 4, 2019 at 18:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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