Subject: [CFRG] K12, HopMAC and short inputs

From: [email-masked]
Date: Sun, 21 Feb 2021 08:04:53 +0000

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. 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.

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

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".

Perhaps one may also argue that for short (say, < 128 bytes) inputs, one 
ought to instead prefer a short-input hash function such as Haraka v2, 
but the state of the art for short input MACs seems unclear.

Thank you for your guidance and time.

Cheers,

Mark 'pandame' Rogers

---

From: Benoit Viguier <[email-masked]>
Date: Wed, 24 Feb 2021 13:37:18 +0100

Dear CFRG,

On 2/21/21 9:04 AM, [email-masked] wrote:

> 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.

> 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.