Re: [CFRG] K12, HopMAC and short inputs

[Benoit Viguier <[e-mail]>]

Dear CFRG,

On 2/21/21 9:04 AM, [e-mail] wrote:

> Hi all,
>
> I am picking up a conversation that I found on /r/crypto on Reddit.
>
> According to Gilles Van Assche (/u/docgcrypto), the Hash-then-MAC
> approach instantiated as HopMAC in the KangarooTwelve draft is needed
> to protect against side-channel attacks like DPA.

Not exactly. In fact it is not needed but just advantageous. The
Hash-then-MAC approach has an advantage over pre-pending the key when
you have to protect against side channel attacks like DPA. In that case,
the hash part (inner call) is keyless and the only part of the
computation that needs to be protected is the MAC part (outer call),
which amounts to a single invocation of the Keccak-p permutation.


> This is not a threat in desktop/server-class machines and only of
> relevance for microcontrollers in certain scenarios as well as perhaps
> hardware implementations.

More exactly, this is a threat in use cases where the adversary can
measure the power consumption of the CPU that does the computation.


> HopMAC causes overhead of an extra invocation, which for very short
> inputs such as key derivation can be very significant.

For very short inputs the relative overhead is indeed significant as the
computation can grow from a single invocation of Keccak-p[12] to two of
those. Absolutely speaking the overhead is very small.


> Perhaps a brief rationale above the definition of HopMAC/the "SHOULD
> use a HASH-then-MAC construction" paragraph could be given as to
> advise people when they can disregard the "SHOULD".

If you find it useful, we could add the following paragraph just before
Section 6 to address this:

In any case, KangarooTwelve MAY be used to compute a MAC with the key 
reversibly prepended or appended to the input. For instance, one MAY 
compute a MAC on short messages simply calling KangarooTwelve with 
the key as the customization string, i.e., MAC = K12(M, Key, L).

Kind regards.

The K12 team.