In Galois/counter mode, the authentication key $H$ is leaked if two distinct messages are encrypted using the same nonce. If someone did end up doing that, then they would need to rekey to get a new $H$ as $H$ is derived only from $K$. So, why not derive $H$ from $K$ and $N$ (the nonce).

  • $\begingroup$ I think changing auth keys is expensive if you use lookup table based implementations (common on CPUs without special binary-field instructions, though I think there are bitslicing implementations as well). $\endgroup$ Jan 29 '18 at 16:45

So, why not derive $H$ from $K$ and $N$ (the nonce).

Well, if you are asking why the original GCM designers made that specific design decision (CodesInChaos point is valid, but software implementations weren't actually considered in the original design):

  • A critical goal in the GCM design was that it be hardware pipeline friendly; that is, you could process the message in a 10-14 stage pipeline (where each AES round was a separate pipeline stage), and that there are minimal wasted steps. Doing some additional computation before you could process the initial AAD data would cause a break in the pipeline, and so violate this goal.

  • It wouldn't help. If the $H$ value was derived from an $N$ and $K$ pair, then if you repeat an $N$ value, you still repeat the $H$ value (and hence leak that $H$ value). What your idea would mean is that the attacker would have to repeat the $N$ value to forge (as the attacker wouldn't know the $H$ value for any other $N$); however that is not a practical issue for attackers, who can freely pick the $N$ value for their forgeries.

  • $\begingroup$ Your second point is well received. But how does my suggestion "cause a break in the pipeline"? Generating $H$ from $K$ and $N$ could be another encryption operation. $\endgroup$
    – Melab
    Jan 29 '18 at 17:24
  • $\begingroup$ @Melab: well, an "encryption operation" requires going through 10-14 pipeline stages, you need the $H$ value to process the first AAD block. Now, I suppose you could place the $GF$ multiplier at the very last pipeline step (assuming that it can be done at least as fast as one AES round; I don't know if that is true); and that would minimize the delay needed; it would look to be (at best) a bit tricky... $\endgroup$
    – poncho
    Jan 29 '18 at 17:34

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.