Re: [Crypto-panel] EXTERNAL: Re: Request for review: draft-irtf-cfrg-kangarootwelve-02

Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com> Mon, 12 October 2020 14:02 UTC

Return-Path: <jeanphilippe.aumasson@gmail.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCF43A14F8 for <crypto-panel@ietfa.amsl.com>; Mon, 12 Oct 2020 07:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.334
X-Spam-Level:
X-Spam-Status: No, score=0.334 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, LH_URI_DOM_IN_PATH=2.331, SPF_HELO_NONE=0.001, 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=gmail.com
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 9Vv9sgeNtUpS for <crypto-panel@ietfa.amsl.com>; Mon, 12 Oct 2020 07:02:20 -0700 (PDT)
Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A02383A1500 for <crypto-panel@irtf.org>; Mon, 12 Oct 2020 07:02:19 -0700 (PDT)
Received: by mail-wr1-x436.google.com with SMTP id b8so6111793wrn.0 for <crypto-panel@irtf.org>; Mon, 12 Oct 2020 07:02:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=NdLkXWxH1y+tWqSmAORbaNOWvGhsokJP0cJxxZjsczc=; b=lvuLsEiljRVN09FkdFGNgrJwned3pg2824oRUbM5UpnYCkKHUM3WgsIDjAWViGMWPI haX7ks3gIVXNwDDSfn9EVZRE5A51vCITRrtoSGSIEK0svz/TswlRq22RP6cPvGkx89Qm NPk/XgHWQzCDCJGT/OM9+2xQgHjKHoI6Xsis7P+mH2MFkPgy+2vvMH4no3ayLUOSooKP cPgH3du+NoF6uOT+AHDGwQn4OiA6z/P6FgF2isQV/WJ7G0UtGzy/BO3ooWme//I+XNaZ juSgwGiUZ3sTEQ+QwDUqJ0q+LGaZDWUisAik+MKZ7zSNwtTwEWVkEqQ8yHLzDXOl0t5+ Hyhg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=NdLkXWxH1y+tWqSmAORbaNOWvGhsokJP0cJxxZjsczc=; b=qjNLbVJBRgYQ0Vh9aA7hPwpOay4yVqOqNy5jfAd9YZSz2COVLxtm92o9i5b60Eh01n 7+ZYQ3QRGnV64i0Qqe2GI9G3b/AvHulDwEscFpmipWq/MCLX4c/+FoSJxwABZPGc5Ism teWUnrrF2TSX1tuylzJanfIATdPQM/HWlrR7T480VUY8KQI3QdF4FJD064BSmOgurTXt WX47UBZIORG5xTSADdQq2m6Dn7utTRgyjtwwvIejPaPl/Rob20C2CkWVpPgvpW8N5K2Q Jt3NzG0deRRFaSapM9vyVAqwoOx0mfUPM0nDcrTPjm85YamDZuyGD74C8WlagB6fr2tk vC/g==
X-Gm-Message-State: AOAM5307vPWFMy9hNSje9lHH8aWd3EqCKKmOrQ5NbdI6clctfHrvEwaw bfam3BksEbNXDROD+rs6fUC20s8rKJoupeUi6Cc=
X-Google-Smtp-Source: ABdhPJwLaek6xWoE12CuH/Kov8ukAMcuUaegvKELidNPxvlZ2FNZPX/pAEQdqawWeH5kWqwp1Ly/3CJvTpK4K1+YnL8=
X-Received: by 2002:a5d:5701:: with SMTP id a1mr8600161wrv.414.1602511337903; Mon, 12 Oct 2020 07:02:17 -0700 (PDT)
MIME-Version: 1.0
References: <bc188f7e-cb30-3aaa-b6a7-88655c841751@cs.ru.nl> <ff010917-47ac-dbc6-8439-663373ddeb87@cs.ru.nl> <9C5E0AC1-E56E-4676-9708-296465BBD87C@nccgroup.com> <619ed4c1210c4502802583e19c6f6c4b@SFHDAG6NODE2.st.com> <CAMr0u6mWLRk7pv56f-10YkRUXwuyfHBP9a7xyXq9o+TYbX1XZw@mail.gmail.com>
In-Reply-To: <CAMr0u6mWLRk7pv56f-10YkRUXwuyfHBP9a7xyXq9o+TYbX1XZw@mail.gmail.com>
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@gmail.com>
Date: Mon, 12 Oct 2020 16:02:06 +0200
Message-ID: <CAGiyFdfdTCqNLa8kV-TPoh3_jRXs3nhMxQk9VJoV0SK=OVURGw@mail.gmail.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Cc: Gilles VAN ASSCHE <gilles.vanassche@st.com>, Alexey Melnikov <alexey.melnikov@isode.com>, Thomas Pornin <thomas.pornin@nccgroup.com>, "crypto-panel@irtf.org" <crypto-panel@irtf.org>, Benoît Viguier <b.viguier@cs.ru.nl>, "draft-irtf-cfrg-kangarootwelve@ietf.org" <draft-irtf-cfrg-kangarootwelve@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000000b5aa305b179bfca"
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/7U8ByNA-mi-kucpoMAJhKuBU8gA>
Subject: Re: [Crypto-panel] EXTERNAL: Re: Request for review: draft-irtf-cfrg-kangarootwelve-02
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Oct 2020 14:02:23 -0000

Yes looks good to me, thanks for asking!

On Mon, Oct 12, 2020 at 3:56 PM Stanislav V. Smyshlyaev <smyshsv@gmail.com>
wrote:

> Dear Jean-Philippe,
>
> >> (Maybe, Jean-Philippe could you confirm?
> Could you please confirm that you are happy with the changes?..
>
> Regards,
> Stanislav
>
>
> On Mon, 5 Oct 2020 at 11:04, Gilles VAN ASSCHE <gilles.vanassche@st.com>
> wrote:
>
>> Dear Alexey,
>>
>>
>>
>> Thanks to Jean-Philippe and Thomas for their comments.
>>
>>
>>
>> We think all comments have been addressed. (Maybe, Jean-Philippe could
>> you confirm?) If indeed the case, can you help to move the document forward
>> ?
>>
>>
>>
>> Thanks & kind regards,
>>
>> Benoît, David, Gilles, Joan and Quynh
>>
>>
>>
>>
>>
>> *From:* Thomas Pornin <thomas.pornin@nccgroup.com>
>> *Sent:* Monday, 21 September 2020 16:18
>> *To:* Benoît Viguier <b.viguier@cs.ru.nl>; Alexey Melnikov <
>> alexey.melnikov@isode.com>; draft-irtf-cfrg-kangarootwelve@ietf.org;
>> crypto-panel@irtf.org
>> *Subject:* Re: EXTERNAL: Re: [Crypto-panel] Request for review:
>> draft-irtf-cfrg-kangarootwelve-02
>>
>>
>>
>> I am not in a good position to make comments on delays, since I also let
>> this email sleep for three weeks...
>>
>>
>>
>> Your changes look good to me.
>>
>>
>>
>> I like the idea that the bulk of the data processing in HopMAC has no
>> dependency on the key; it has indeed strong benefits with regard to side
>> channel attacks. Of course, it unavoidably implies that HopMAC relies on
>> the collision resistance of the keyless hash function. In the aftermath of
>> the MD5 and SHA-1 attacks (in the 2000s), there has been a trend of
>> shunning collision resistance, and insisting on using only
>> (second-)preimage resistance; that's how, for instance, Ed25519 signatures
>> in "pure" mode insist on generating the challenge as H(pkey+R+message) and
>> not H(pkey+R+H(message)). This trend implies some practical limitations
>> (e.g. "pure" Ed25519 signatures make it much more difficult to process
>> X.509 certificates in memory-constrained environments). I think your choice
>> in HopMAC is a better trade-off; keyless processing of the bulk of the data
>> has tangible practical benefits, and if K12 is not collision-resistant then
>> the foundation of its other security properties becomes quite flaky.
>>
>>
>>
>> Thomas
>>
>>
>>
>> *From: *Benoît Viguier <b.viguier@cs.ru.nl>
>> *Date: *Tuesday, September 1, 2020 at 10:38
>> *To: *Thomas Pornin <thomas.pornin@nccgroup.com>, Alexey Melnikov <
>> alexey.melnikov@isode.com>, "draft-irtf-cfrg-kangarootwelve@ietf.org" <
>> draft-irtf-cfrg-kangarootwelve@ietf.org>, "crypto-panel@irtf.org" <
>> crypto-panel@irtf.org>
>> *Subject: *Re: EXTERNAL: Re: [Crypto-panel] Request for review:
>> draft-irtf-cfrg-kangarootwelve-02
>>
>>
>>
>> Dear Thomas, Dear Alexey, Dear Crypto Panel members,
>>
>> We would like to thank you for your time into reviewing our draft
>> and providing us with your constructive comments.
>>
>> We apologize for the delays (corona & vacations...) and provide you here
>> with
>> our modifications to the draft:
>> https://github.com/cfrg/draft-irtf-cfrg-kangarootwelve/commit/70eff423aa57e9e34121951da2764b5ed73df988
>> <https://gbr01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcfrg%2Fdraft-irtf-cfrg-kangarootwelve%2Fcommit%2F70eff423aa57e9e34121951da2764b5ed73df988&data=02%7C01%7Cthomas.pornin%40nccgroup.com%7Ce1e346d59c784399ad6b08d84e84a3e7%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637345678881062176&sdata=s4Pc12tumBCNxqhLGREPxcpTvDU%2F5eyV6awv9a9fQmE%3D&reserved=0>
>> .
>>
>> On 7/17/20 11:57 PM, Thomas Pornin wrote:
>>
>> Here is my review of draft-irtf-cfrg-kangarootwelve-02:
>>
>>
>>
>> General comments:
>>
>>
>>
>> The function is well described. The specification is not self-contained
>>
>> since it relies on FIPS 202, but that's not a problem in my opinion (there
>>
>> already are other RFCs that reference FIPS 202).
>>
>>
>>
>> The function already exists and is specified in a note published on
>>
>> eprint since 2016, so there is no point in changing it now; this is an
>>
>> RFC that describes an existing situation, not one that introduces new
>>
>> stuff (otherwise, I would insist, for aesthetical reasons, on making
>>
>> length_encode() use little-endian instead of the current big-endian).
>>
>> Additionally we added links to the publications at the ACNS
>> conference 2014 and 2018 for KangarooTwelve and the Sakura tree hashing.
>>
>> Some poor soul, somewhere, will want to make a MAC out of K12 and will
>>
>> try to use it in HMAC. This is probably not a very good idea, though
>>
>> it won't be weak. HMAC requires knowledge of the "block size" of the
>>
>> algorithm, so that block size should be specified somewhere. Intuitively,
>>
>> I suppose the "block size" is 168 bytes, but it would be better to state
>>
>> it explicitly somewhere.
>>
>>
>>
>> Also, some guidance about a better way to turn K12 into a MAC would be
>>
>> helpful. Normally, a simple K12(key || data) would be enough, provided
>>
>> that the concatenation of 'key' and 'data' is unambiguous. It is
>>
>> tempting to use the key as customization string, but then, you do not
>>
>> have a customization string anymore. A related question is whether the
>>
>> MAC output length should be part of the input/customization string.
>>
>> We added a paragraph on that subject in the Security Consideration
>> section.
>> We present HopMAC(K, M, C, L) = K12( Key, K12(M, C, 32), L) to describe
>> a way to build a MAC from K12.
>>
>> Particular comments:
>>
>>
>>
>> page 2: "splits the input message in fragments" -> "splits ... into
>> fragments"
>>
>> (also page 3)
>>
>> Edited.
>>
>>  page 3: "does not have overhead": this is a bold statement. What is meant
>>
>> here is that the tree hashing mode of K12 does not introduce _additional_
>>
>> overhead (due to the tree hashing mode) compared with, say, SHAKE; but
>>
>> there remains the elementary overhead which makes it so that, for
>> instance,
>>
>> hashing 10 bytes is not less expensive than hashing 120 bytes.
>>
>>
>>
>> Speaking of overhead, it may be worth pointing out that the tree mode
>>
>> implies maintaining two separate Keccak contexts (at least for inputs
>>
>> longer than 8192 bytes), hence double the RAM usage; this may matter
>>
>> for constrained embedded devices (i.e. low-end smartcards and
>>
>> microcontrollers, where 200 bytes of RAM are a lot).
>>
>>
>>
>> page 4: "from n to m exclusive" is a bit confusing since byte at index m
>>
>> is excluded, but byte at index n is included. Maybe: "selection of bytes
>> from
>>
>> index n (inclusive) to m (exclusive)"? Also say somewhere that the first
>>
>> byte of a string has index 0 (i.e. this is C/Rust, not Pascal).
>>
>> Edited.
>>
>> page 4: "x**y denotes x multiplied by itself y times" -> this would
>>
>> actually be x**(y+1) (if you multiply x by itself _once_, you get x*x).
>>
>> Edited.
>>
>> page 4: "the number of output bytes requested" -> this lacks a verb;
>>
>> probably: "is the requested number of output bytes"
>>
>> Edited.
>>
>> page 5: "First the message is padded with zeroes to the closest multiple
>> of
>>
>> 168 bytes.  Then a byte `80` is XORed to the last byte of the padded
>>
>> message.  and the resulting string is split into a sequence of 168-byte
>>
>> blocks."
>>
>> -> This could be made clearer, first to indicate that it is the length,
>>
>> in bytes, of the padded message which is to be a multiple of 168; also,
>>
>> that the "closest" is really a rounding-up (e.g. with a 169-byte input,
>>
>> we really need to append 167 other bytes, even though 168 is arguably
>>
>> much closer to 169 than 336). There should be an explicit specification
>>
>> about what to do if the input size already has a size multiple of 168:
>>
>> should we add 168 extra bytes of value zero, or none at all? Note that,
>>
>> in the latter case, there must be a special case for an input of length
>>
>> 0: if the padded input consists of no byte at all, then it becomes
>>
>> difficult to XOR 0x80 into "the last byte".
>>
>> We clarify that the length of the F function is positive.
>> This resolve the problem of inputs consisting of no bytes.
>> In the definition of KangarooTwelve in section 2.2, there are no calls to
>> F
>> with input of length 0.
>>
>> We clarify the rounding up to the next multiple of 168.
>>
>> (Three paragraphs later, we learn that the input length is at least
>>
>> 1 byte, which avoids any issue related to a zero-length input; this
>>
>> should probably be explained a bit earlier in the text.)
>>
>> Edited.
>>
>>  page 11: "against all attacks" (end of first paragraph of section 5):
>>
>> this lacks a final dot.
>>
>> Edited.
>>
>>
>>
>> Thomas
>>
>> We are open to any additional feedback.
>>
>> --
>>
>> Kind regards,
>>
>>
>>
>> Benoît Viguier
>>
>> Software Engineer - PhD Student | Cryptography & Formal Methods
>>
>> Radboud University | Mercator 1, Toernooiveld 212
>>
>> 6525 EC Nijmegen, the Netherlands | www.viguier.nl <https://gbr01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.viguier.nl%2F&data=02%7C01%7Cthomas.pornin%40nccgroup.com%7Ce1e346d59c784399ad6b08d84e84a3e7%7Ca41111be486b45f68bd0ee01a62f368e%7C0%7C0%7C637345678881067157&sdata=bxZRTB5IWIUpqrBgVBRrXvguBjmBgJ%2Fl9wtkc09aAPo%3D&reserved=0>
>>
>> _______________________________________________
>> Crypto-panel mailing list
>> Crypto-panel@irtf.org
>> https://www.irtf.org/mailman/listinfo/crypto-panel
>>
>