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 >> >
- Re: [Crypto-panel] EXTERNAL: Re: Request for revi… Thomas Pornin
- [Crypto-panel] Request for review: draft-irtf-cfr… Nick Sullivan
- Re: [Crypto-panel] Request for review: draft-irtf… Stephen Farrell
- Re: [Crypto-panel] Request for review: draft-irtf… Nick Sullivan
- Re: [Crypto-panel] Request for review: draft-irtf… Jean-Philippe Aumasson
- [Crypto-panel] Request for review: draft-irtf-cfr… Alexey Melnikov
- [Crypto-panel] Request for review: draft-irtf-cfr… Alexey Melnikov
- Re: [Crypto-panel] Request for review: draft-irtf… Chloe Martindale
- Re: [Crypto-panel] Request for review: draft-irtf… Alexey Melnikov
- Re: [Crypto-panel] EXTERNAL: Re: Request for revi… Thomas Pornin
- Re: [Crypto-panel] EXTERNAL: Re: Request for revi… Alexey Melnikov
- Re: [Crypto-panel] Request for review: draft-irtf… Stanislav V. Smyshlyaev
- Re: [Crypto-panel] Request for review: draft-irtf… Jean-Philippe Aumasson
- Re: [Crypto-panel] Request for review: draft-irtf… Stanislav V. Smyshlyaev
- Re: [Crypto-panel] EXTERNAL: Re: Request for revi… Benoît Viguier
- Re: [Crypto-panel] Request for review: draft-irtf… Leonid Reyzin
- Re: [Crypto-panel] Request for review: draft-irtf… Chloe Martindale
- Re: [Crypto-panel] Request for review: draft-irtf… Leonid Reyzin
- Re: [Crypto-panel] EXTERNAL: Re: Request for revi… Thomas Pornin
- Re: [Crypto-panel] EXTERNAL: Re: Request for revi… Gilles VAN ASSCHE
- Re: [Crypto-panel] EXTERNAL: Re: Request for revi… Stanislav V. Smyshlyaev
- Re: [Crypto-panel] EXTERNAL: Re: Request for revi… Jean-Philippe Aumasson
- Re: [Crypto-panel] EXTERNAL: Re: Request for revi… Stanislav V. Smyshlyaev
- Re: [Crypto-panel] Request for review: draft-irtf… Chloe Martindale
- Re: [Crypto-panel] Request for review: draft-irtf… Stanislav V. Smyshlyaev
- Re: [Crypto-panel] Request for review: draft-irtf… Leonid Reyzin
- Re: [Crypto-panel] Request for review: draft-irtf… Leonid Reyzin
- Re: [Crypto-panel] Request for review: draft-irtf… Chloe Martindale