[CFRG] K12, HopMAC and short inputs

pandame@firemail.cc Sun, 21 February 2021 08:05 UTC

Return-Path: <pandame@firemail.cc>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BEF73A17D2 for <cfrg@ietfa.amsl.com>; Sun, 21 Feb 2021 00:05:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.788
X-Spam-Level:
X-Spam-Status: No, score=-0.788 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_RP_RNBL=1.31, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=firemail.cc
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yGh9fbNrSkg3 for <cfrg@ietfa.amsl.com>; Sun, 21 Feb 2021 00:04:58 -0800 (PST)
Received: from mail.cock.li (mail.cock.li [37.120.193.124]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F01663A17D0 for <cfrg@irtf.org>; Sun, 21 Feb 2021 00:04:56 -0800 (PST)
MIME-Version: 1.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=firemail.cc; s=mail; t=1613894693; bh=BUXLpfnWWXCeoJTVmV4yUIjm67/edr675KhRJ5OTAIc=; h=Date:From:To:Subject:From; b=KNRElnj2pnqgFetLlXIEv/WtO/2u2GqoVU076unBmaxn55ssT5wje2sIgjtZVqTSE WpICfD0SgbvqSyGlVMH1q+K0hNwrTrv0xQnihDUueXyaOtc3wcjm3ACThLPiNpPYbe 16VGTGAJz6EVI620EjqoEHD/bKEmfuyXXkGO9CVdc1uvoeAGU2f96n/U7VblPPK1I9 2XJ0Hx9+EiPMb1jouQjQ6Zhop/W4PbkP6aAMLWlRGT1MEAWvYKeIP+RIXVlgpjcPmy fzRqdLVL3yGJp8Rv+xtZxMrjUTcU5QYIn1v3Ybht6WNprBLyE+C+QID9OBPAvDzWcE u4O+UoedWFX9g==
Content-Type: text/plain; charset=US-ASCII; format=flowed
Content-Transfer-Encoding: 7bit
Date: Sun, 21 Feb 2021 08:04:53 +0000
From: pandame@firemail.cc
To: cfrg@irtf.org
Message-ID: <33de59016299a9fc161550fc928af4d9@firemail.cc>
X-Sender: pandame@firemail.cc
User-Agent: Roundcube Webmail/1.3.15
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/m5YYKyhTIBBY4AmVwBldNxOw7WQ>
Subject: [CFRG] K12, HopMAC and short inputs
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Feb 2021 08:30:27 -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