Return-Path: 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 662E91310DA for ; Tue, 18 Dec 2018 08:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=paragonie-com.20150623.gappssmtp.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 tK5R8ZlmIF-R for ; Tue, 18 Dec 2018 08:28:39 -0800 (PST) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 F1D7D130F4F for ; Tue, 18 Dec 2018 08:28:33 -0800 (PST) Received: by mail-lj1-x22c.google.com with SMTP id k15-v6so14738910ljc.8 for ; Tue, 18 Dec 2018 08:28:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=paragonie-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C54LgJvc8j9QWQh55V77iFu64QS8ufNlVnJlhbXt27c=; b=lB4cS3NZPJrYU77Ooi559y8nsL8r7MAP7rJpbiAQpu/G+ekLuKUbVBavUQ4TP8c0Kf +mxdgxsjIG5F9S6oTCyZhHj4KBrh8YDLKH0HGlsFtjvYPIEfisgRdA0avHGGtxyXvABV koP+q9qxU/rQm6rYoCEp3ENTxN1zoazQkwLCamkCD3WLN9YjOPT99gT7dd5nZOrQSBZV umVO50+FUfaejKVwn+Wx0r5hpatDjNEsJ33vHPp6tiIm4agFfW6UQ9w6nagt7w9UCnxt no6gReaD1HWoxXw05AoiLC/wiJYVVL78NMabPZeypi1y2BOhWK0HCdcavC75xQop+EWQ plVw== 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=C54LgJvc8j9QWQh55V77iFu64QS8ufNlVnJlhbXt27c=; b=DZ9gsYu/WhJPn38iFw93V5cu48qDraE3OpTTEz2jQSXWyry4m1NaTIvjfJJzqsSLwe fvTPcig453U/epzkNXXPWlmuHRXz/c4ODP46oO3pLj37vb7+ybLMP7wknXEMP3Bd7w2J Td4Li5j50bU+9k2IMgkgne7VhJfKzU6WQUfeFnorenkc2/Nb7wKj4SzjHLvdRNJsfedZ XVo5wGl6zxsRm7N0yQeHvEeQranFjX+RsGbEEElIfCvi3q3f+CuoGHS3te1/jUHkE6Md HijHCBbb8FVbw9DxNlzzkk5JKPIcQkR3ymTMo0fd6aKbZXH0EwZeMK2VYykRyGJAWcOh kyZg== X-Gm-Message-State: AA+aEWbFp0lH+4Nxex2E6PIvuKN1yQSbvYaStFJ7lsPrKZVT/BnxzMM/ 50RP4cii074YRTMGRh0Dg0/HHJtaIBlzUtQiaLtpHg== X-Google-Smtp-Source: AFSGD/WiyoZhG1RBszWgjDTqZ152K9bwtvRWW0rSOLzE9QAehMzjhCkbYEUY0ZTl1iS2B8KgBYftwSG9UnjTvyCvT3c= X-Received: by 2002:a2e:9e95:: with SMTP id f21-v6mr10539589ljk.128.1545150511983; Tue, 18 Dec 2018 08:28:31 -0800 (PST) MIME-Version: 1.0 References: <99CCB4A1-9CC1-4611-95C5-CEEA985024F8@gmail.com> In-Reply-To: <99CCB4A1-9CC1-4611-95C5-CEEA985024F8@gmail.com> From: Scott Arciszewski Date: Tue, 18 Dec 2018 11:28:18 -0500 Message-ID: To: Neil Madden Cc: cfrg@ietf.org Content-Type: multipart/alternative; boundary="000000000000644071057d4e63e1" Archived-At: Subject: Re: [Cfrg] Review of draft-arciszewski-xchacha-02 X-BeenThere: cfrg@irtf.org 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: Tue, 18 Dec 2018 16:28:43 -0000 --000000000000644071057d4e63e1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the review and feedback, Neil. I've made some other changes on Github and was going to get draft03 ready today. I'll incorporate your suggestions as well. Aside: Based on the responses to the "Adoption call for draft-arciszewski-xchacha" thread , I believe this will also be the last draft before CFRG adoption (which presumably will change the filename in future editions). Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises On Tue, Dec 18, 2018 at 7:15 AM Neil Madden wrote= : > I=E2=80=99ve had a good look through draft-arciszewski-xchacha-02 from an > implementor=E2=80=99s perspective. I think it=E2=80=99s a good draft that= describes the > algorithms well. I have some comments on a few parts of the text below: > > Section 1, Introduction: > > The text currently says: > > "However, a more straightforward strategy can prevent nonce misuse > conditions in environments where a large number of messages are > encrypted.=E2=80=9D > > We should be careful with the word =E2=80=9Cprevent=E2=80=9D here. Nonce = reuse can still > happen with large random nonces, even if it is less likely - e.g., with a > broken or compromised PRNG. See for example failures in the Android > SecureRandom implementation that led to compromise of a Bitcoin transacti= on > due to nonce reuse in an ECDSA signature [1]. In this case the random non= ce > would have been 256 bits I believe, so even larger than that for XChaCha. > > I think =E2=80=9Cmore straightforward=E2=80=9D is also potentially subjec= t to debate (if > you ignore the S2V parts, SIV is pretty simple). Perhaps wording along th= e > following lines: > > =E2=80=9CHowever, misuse resistant cipher constructions come at a cost in > performance as they must necessarily make two passes over the > message to be encrypted. An alternative strategy can significantly > reduce the chance of accidental nonce reuse in environments > where a large number of messages are encrypted. [Simply use =E2=80=A6]=E2= =80=9D > > Ironically, the main reason that I am interested in XChaCha20 is precisel= y > because the larger nonce makes it more suitable for use in an SIV > construction, as per my recent draft. > > Section 2.1 Motivation for XChaCha20-Poly1305: > > It might be worth clarifying that a 96-bit nonce is too short to generate > randomly where you need to encrypt lots of messages with the same key (mo= re > than a few million). If you are doing DH with forward secrecy and > generating fresh keys for each message anyway, then a 96-bit random nonce > is fine. > > The text: "A more > conservative threshold (2^-32 chance of collision) still allows for > 2^64 messages to be sent under a single key.=E2=80=9D > > This should say =E2=80=9Cstill allows for 2^80 messages to be sent under = a single > key.=E2=80=9D > > 2.2 HChaCha20 > > This could do with a reference to RFC 7539 section 2.3. It could be a bit > clearer that the ChaCha20 block counter is replaced with the first 32 bit= s > of the nonce (in little-endian) and the remaining 96 bits are used as per > usual in ChaCha20. > > I have verified the supplied test vector with an independent > implementation of HChaCha20 that I wrote, and it matches. > > 2.3.1 XChaCha20 Pseudocode: > > The code doesn=E2=80=99t include the 4 NUL bytes in the nonce it passes t= o > ChaCha20. > > Test vectors: > > I have verified that the test vectors in A.1 and A.2 and produce the same > results as documented. > > [1] > https://www.symantec.com/connect/blogs/android-cryptographic-issue-may-af= fect-hundreds-thousands-apps > > Kind regards, > > Neil > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --000000000000644071057d4e63e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the review and feedback, Neil.
I've made some other changes on Github and was going to get draft03= ready today. I'll incorporate your suggestions as well.

<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace">Aside= : Based on the responses to the "Adoption call for draft-arciszewski-x= chacha" thread, I believe this will also be the last draft befor= e CFRG adoption (which presumably will change the filename in future editio= ns).
=
Scott Arcisz= ewski
Chief Development Offi= cer


On Tue, Dec 18, 2018 at 7:15 AM Neil M= adden <neil.e.madden@gmail.co= m> wrote:
I=E2=80=99ve had a good look through draft-arciszewski-xchacha-02 from an = implementor=E2=80=99s perspective. I think it=E2=80=99s a good draft that d= escribes the algorithms well. I have some comments on a few parts of the te= xt below:

Section 1, Introduction:

The text currently says:

"However, a more straightforward strategy can prevent nonce misuse
=C2=A0 =C2=A0conditions in environments where a large number of messages ar= e
=C2=A0 =C2=A0encrypted.=E2=80=9D

We should be careful with the word =E2=80=9Cprevent=E2=80=9D here. Nonce re= use can still happen with large random nonces, even if it is less likely - = e.g., with a broken or compromised PRNG. See for example failures in the An= droid SecureRandom implementation that led to compromise of a Bitcoin trans= action due to nonce reuse in an ECDSA signature [1]. In this case the rando= m nonce would have been 256 bits I believe, so even larger than that for XC= haCha.

I think =E2=80=9Cmore straightforward=E2=80=9D is also potentially subject = to debate (if you ignore the S2V parts, SIV is pretty simple). Perhaps word= ing along the following lines:

=E2=80=9CHowever, misuse resistant cipher constructions come at a cost in performance as they must necessarily make two passes over the
message to be encrypted. An alternative strategy can significantly
reduce the chance of accidental nonce reuse in environments
where a large number of messages are encrypted. [Simply use =E2=80=A6]=E2= =80=9D

Ironically, the main reason that I am interested in XChaCha20 is precisely = because the larger nonce makes it more suitable for use in an SIV construct= ion, as per my recent draft.

Section 2.1 Motivation for XChaCha20-Poly1305:

It might be worth clarifying that a 96-bit nonce is too short to generate r= andomly where you need to encrypt lots of messages with the same key (more = than a few million). If you are doing DH with forward secrecy and generatin= g fresh keys for each message anyway, then a 96-bit random nonce is fine.
The text: "A more
=C2=A0 =C2=A0conservative threshold (2^-32 chance of collision) still allow= s for
=C2=A0 =C2=A02^64 messages to be sent under a single key.=E2=80=9D

This should say =E2=80=9Cstill allows for 2^80 messages to be sent under a = single key.=E2=80=9D

2.2 HChaCha20

This could do with a reference to RFC 7539 section 2.3. It could be a bit c= learer that the ChaCha20 block counter is replaced with the first 32 bits o= f the nonce (in little-endian) and the remaining 96 bits are used as per us= ual in ChaCha20.

I have verified the supplied test vector with an independent implementation= of HChaCha20 that I wrote, and it matches.

2.3.1 XChaCha20 Pseudocode:

The code doesn=E2=80=99t include the 4 NUL bytes in the nonce it passes to = ChaCha20.

Test vectors:

I have verified that the test vectors in A.1 and A.2 and produce the same r= esults as documented.

[1] https://www.symantec.com/connect/blogs/android-cryptographic-issue-may= -affect-hundreds-thousands-apps

Kind regards,

Neil
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
--000000000000644071057d4e63e1--