Re: [CFRG] K12, HopMAC and short inputs

Benoit Viguier <> Wed, 24 February 2021 12:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DA4B73A150E for <>; Wed, 24 Feb 2021 04:37:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XDIaPWrg6Tn6 for <>; Wed, 24 Feb 2021 04:37:31 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5BF863A1510 for <>; Wed, 24 Feb 2021 04:37:30 -0800 (PST)
Received: from [] ( []) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPSA id 20CB03280089 for <>; Wed, 24 Feb 2021 12:37:19 +0000 (UTC)
References: <>
From: Benoit Viguier <>
Message-ID: <>
Date: Wed, 24 Feb 2021 13:37:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------116FA4496CCFBEA570DAF303"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [CFRG] K12, HopMAC and short inputs
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Feb 2021 12:37:37 -0000

Dear CFRG,

On 2/21/21 9:04 AM, 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.