From nobody Thu Jan 28 09:21:34 2021 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 AA49E3A1655 for ; Thu, 28 Jan 2021 09:21:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=bitlogik.fr 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 F6ns6zNwX6h7 for ; Thu, 28 Jan 2021 09:21:27 -0800 (PST) Received: from smtp-out-2-17.monarobase.net (smtp-out-2-17.monarobase.net [178.33.70.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCF9F3A16AE for ; Thu, 28 Jan 2021 09:21:25 -0800 (PST) Received: from s15.monarobase.net ([54.38.67.239]) by mx2.monarobase.net with esmtpsa (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1l5Ayb-00043q-I7 for cfrg@irtf.org; Thu, 28 Jan 2021 18:21:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bitlogik.fr ; s=default; h=Content-Type:MIME-Version:Subject:Message-ID:To:From:Date: Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=cz6w0Xg1zzdUmwxc0b671fXWW0pcOvS5oUpg1txMXgU=; b=LPJ3hR8b2bPo1dxgsQbwWXegu6 SN7kKksvCgY27lWXDS2mpYl1mVA2CjAgLiHnA2KXEtmuhv3Sj7vaGBJg3zkVYWEBjVPxWXsQuVmuq wALUjEUTIgJXAsEqDvv/TAS+W3RfUJevylhQkc8ShUhUt286Ptt5npACtiaB5lZQv1yTBrWskN+h2 q/RTeeg6naCopYkvk8MX9RQRGoEx+RUjWuDtMRElg+l0K7dErnmwWE+Kt6KyL3FO5hkflpNoj3TyZ naYsi9ZSQBpPPhql4yoSVtPc0ZkQG5N1TSjFa0I532htqCtQO6OPpCXXnj+I1uMJB6O8w/izob4Fj IV2Fpt3w==; Received: from lfbn-idf1-1-284-76.w86-195.abo.wanadoo.fr ([86.195.122.76]:51798 helo=DESKTOP-5NEDTME) by s15.monarobase.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1l5AyY-000cfP-9h for cfrg@irtf.org; Thu, 28 Jan 2021 18:20:58 +0100 Date: Thu, 28 Jan 2021 18:20:57 +0100 From: Antoine FERRON To: "=?utf-8?Q?cfrg=40irtf.org?=" Message-ID: X-Mailer: Mailspring MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="6012f279_0_e30f6965" X-AuthUser: antoine.ferron@bitlogik.fr X-Originating-IP: 54.38.67.239 X-SpamExperts-Domain: s15.monarobase.net X-SpamExperts-Username: 54.38.67.239 Authentication-Results: monarobase.net; auth=pass (login) smtp.auth=54.38.67.239@s15.monarobase.net X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.41) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT+luYCipqaLiAw+SDcuvCe6PUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wstP7rBrR4jnxptJR5eGwCKj/EwzSHE5FGYwwjsNRPCL6W IMUPMEUk9Ablrn39oGvmD6wdmZPcItWbGe10hXJtM46cdhymWCUWb6gn2ylo1JVa34Z1otl4iuaP HNrMYCFUGpRhHNn8VjgSXaD0jp9k1z6XV1PT2oYJbJGpf/4B35otTbzF8bFslzcWfB/84WWCENCD dU5pmq7Nfx7x/NBcWx9EHvLtgYzrHdwxf81h48E95bF8tPKjnaWlQ6fjTEeg4CZvTGBeutAohO1y UnDCPEg+PVRTiaxPY52n0Pp/86b+Sk5ZBXUgt9/X6plqv8Jl041btgY00t8ZwQGEpPru7jvpIyNK kis6HYv8iaGiztnjGmKA6S0KnpdzPXa1+MU93SsS4aMXJmiJ2G0eb5ahmOap1AH5T2bmFf9yajHU Qg8uTrfOE379hgV3meGUJIMksVlXZWxasRfFjM8m8h7IISdVKyA8/8yCpIYzH3apf78hv/eAPXF2 /g6Nh7EU3uLWtCYqRdQz+dzNvWLYEPsDQp16bft71z/0otJevHbhXIhYqPARXStQkVeR6QklLn1i 7wLmYnntkb2D1B9sGkgXc5rIRQvHwzHdV6TBpul54dO6UlGm0ycQh0Ylbt1+Ear3Y80OmAux3oN1 3+ztUznereouoqTztWBFJTG8CtyVBeqwCg9RO9BdjShBn4oL6vWfSuzyaKL63Mse4+B85fkA9y2o rqE8eeQMw/lFSvIGyQ5Vxm/bnhrVKymAutkEJf+F5AfNErjKtzXnD4N0FWfB647lNwN4qOsSZg+f YhVZG8PM6+s3d7prPjz0Ivh3QSebTo30s4XN7YvQ1rny+tUsS5oM2HkhMHRtZmszIG8lBhzugfuS xbVdMxDGUckqapQwbVA/fmexh8/zhz5EUrcqrtJqFSM8pFGmnOwj5WaEkTF+3XLsa7zHsxAzT4Df aeg= X-Report-Abuse-To: spam@mx1.monarobase.net Archived-At: Subject: [CFRG] [draft-irtf-cfrg-xchacha] Xchacha20 nonce wrap 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: Thu, 28 Jan 2021 17:21:32 -0000 --6012f279_0_e30f6965 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Dear crypto researchers and standard writers, Some chairs members suggested to me that I share the following considerat= ions to this C=46RG mailing list, so that all members can discuss this po= int. We are seeking great interest in the =22XChaCha=22 IET=46 draft standard = (https://tools.ietf.org/html/draft-irtf-cfrg-xchacha-03). We developed a = new =22secure cloud=22 service with client-side encryption. And we have s= elected the AEAD=5FXChaCha20=5FPoly1305 algorithm to encrypt the files ch= unks. So this algorithm is the root base of the system (https://github.co= m/bitlogik/guardata/blob/master/guardata/crypto/secretbox2.py=23L65). We = use libsodium (https://libsodium.gitbook.io)through the pyNaCl wrapper, w= hich implements it (https://github.com/pyca/pynacl/blob/master/src/libsod= ium/src/libsodium/crypto=5Faead/xchacha20poly1305/sodium/aead=5Fxchacha20= poly1305.c) directly with SecretBox (https://github.com/pyca/pynacl/blob/= master/src/libsodium/src/libsodium/crypto=5Fsecretbox/xchacha20poly1305/s= ecretbox=5Fxchacha20poly1305.c). As I went deeper and deeper in the technical details of this matter, most= ly to check everything is right and our system follows the standards, I s= tumbled upon a tiny but recurring issue about the standard (https://www.c= ryptopp.com/wiki/ChaChaTLS=23Sharp=5FEdges). Indeed since the creation of= the Salsa parent cipher, nothing was set forth about what should happen = once the maximum nonce value is reached and the next block increments the= nonce value. Well, initially the nonce is supposed to start at 0 and rea= ching the end is not realistic, or at least there are some limitations pr= eventing this. But new usages of the cipher (as yours IET=46 draft) and l= arger file size can overpass this, so the issue is resurfacing. The most = annoying effect is the fact the behaviour when the nonce wraps, can be di= fferent depending of the implementation. That is expected, since no stand= ard are telling about this point. See the pending Crypto++ issue about Ch= achaTLS, which is fully related : https://github.com/weidai11/cryptopp/is= sues/790 was actually closed because no one cares : =22no one has told wh= at to do=22. If I'm correct, using IET=46 Xchacha20, the nonce wrap can occur after 4x= 8 32 bits =3D 4 billions blocks, when the given =22remaining 8 byte nonce= =22 is near the maximum value 8x8 =3D 64 bits minus 1 (or 2) : 0x=46=46=46= =46=46=46=46=46=46=46=46=46=46=46=46=46. That means, that with a =22random=22 nonce ending with 0x=46=46=46=46=46=46= =46=46=46=46=46=46=46=46=46E, the maximum file size before a nonce wrap h= appens is 256 GB (4 billion blocks of 64 bytes). What are you personal opinions on this matter=3F What do you recommend to enforce about this topic=3F I can see different solutions : Limiting the maximum file size when using XChacha20 to 256 GB, thus elimi= nating the issue possibility. That's just restricting the standard use, a= s it is supposed to accommodate =22unlimited=22 size (2=5E64) with its ex= tended nonce. Accepting a nonce wrap of the 12 bytes counter, so let the maximum file s= ize to =2264 bits=22 (2=5E64-1). Observing the actual implementations, th= is would need to clarify what is the expected behaviour when the nonce wr= apping happens : just =22cycle=22 it back to 0, or increase the first word of the nonce, and rekey before resetting the nonc= e The libsodium library (and also Botan) is doing the latest, meaning it : defines the maximum file size for Xchacha20 to 64 bits long : crypto=5Fae= ad=5Fxchacha20poly1305=5Fietf=5FMESSAGEBYTES=5FMAX is 2=5E64-1-MacSz changes the other nonce part when the 12 bytes internal nonce is back to = 0. As explained in the Crypto++ issue about this, I'm not a fan of the =22ke= y=22 nonce increment, as this is dangerous. This is described as a =22wil= d memory write=22 in the Crypto++ issue. =46or example if anyone is using= a previous used nonce set and this new incremented nonce will be unknown= by the system, so it can reuse the same nonce as the one incremented. Th= e risk is very low, since the nonce has an extended size, it is hard to t= rack set of used nonce, and mostly used with a random generator. One can = also just use incremented nonce as a method to prevent nonce reuse, and t= his automatic increment will screw everything up with very large files. We would be grateful if the current IET=46 proposal could be updated with= some details about this matter. Whatever the choice, distinctive and cle= ar instructions are better that nothing, else this leads to implementatio= ns divergence, as this is already the case for existing affiliated standa= rds. Any limitations or clarification are welcome, else people are doing = =22free=22 things which can be dangerous in terms of security. We thank y= ou for your effort and time into standardising this, let us know your opi= nion. Regards, =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Antoine =46ERRON Pr=C3=A9sident =E2=80=94 BitLogiK bitlogik.fr (https://bitlogik.fr) =E2=80=94 PGP Key ID=2322=4695B31 (http= s://pgp.key-server.io/0xE353957C22=4695B31) --6012f279_0_e30f6965 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
Dear crypto= researchers and standard writers,

Some chairs members sugges= ted to me that I share the following considerations to this C=46RG mailin= g list, so that all members can discuss this point.
We are se= eking great interest in the =22XChaCha=22 IET=46 draft standard. We developed a new =22secure clou= d=22 service with client-side encryption. And we have selected the AEAD=5F= XChaCha20=5FPoly1305 algorithm to encrypt the files chunks. So this algor= ithm is the root base of the system.= We use lib= sodium through the pyNaCl wrapper, which implements it direct= ly with Sec= retBox.

As I went deeper and deeper in the technical= details of this matter, mostly to check everything is right and our syst= em follows the standards, I stumbled upon a tiny but <= font style=3D=22font-size:14.5px=22>recurring issue about the standard. Indee= d since the creation of the Salsa parent cipher, nothing was set forth ab= out what should happen once the maximum nonce value is reached and the ne= xt block increments the nonce value. Well, initially the nonce is suppose= d to start at 0 and reaching the end is not realistic, or at least there = are some limitations preventing this. But new usages of the cipher (as yo= urs IET=46 draft) and larger file size can overpass this, so the issue is= resurfacing. The most annoying effect is the fact the behaviour when the= nonce wraps, can be different depending of the implementation. That is e= xpected, since no standard are telling about this point. See the pending = Crypto++ issue about ChachaTLS, which is fully related :  https://github.com/weidai11/cryptopp/issues/790=  was actually closed because no one cares : =22no one has told what = to do=22.

If I'm correct, using IET=46 Xchacha20, the nonce wr= ap can occur after 4x8 32 bits =3D 4 billions blocks, when the given =22r= emaining 8 byte nonce=22 is near the maximum value 8x8 =3D 64 bits minus = 1 (or 2) : 0x=46=46=46=46=46=46=46=46=46=46=46=46=46=46=46=46.
Th= at means, that with a =22random=22 nonce ending with 0x=46=46=46=46=46=46= =46=46=46=46=46=46=46=46=46E, the maximum file size before a nonce wrap h= appens is 256 GB (4 billion blocks of 64 bytes).

<= div>What are you= personal opinions on this matter=3F
What do you recommend to enfor= ce about this topic=3F

I can see different solutions :=
  • Limiting the maximum file size when using XChacha20 to 256 GB, = thus eliminating the issue possibility. That's just restricting the stand= ard use, as it is supposed to accommodate =22unlimited=22 size (2=5E64) w= ith its extended nonce.
  • Accepting a nonce wrap of the 12 = bytes counter, so let the maximum file size to =2264 bits=22 (2=5E64-1). = Observing the actual implementations, this would need to clarify what is = the expected behaviour when the nonce wrapping happens :
    • = just =22cycle=22 it back to 0, or
    • increase the first wor= d of the nonce, and rekey before resetting the nonce
      <= /li>
The libsodium library (and also Botan) is doing the latest, meaning= it :
  • defines the maximum file size for Xchacha20 to 64 bi= ts long : crypto=5Faead=5Fxchacha20poly1305=5Fietf=5FMESSAGEBYTES=5FMAX i= s 2=5E64-1-MacSz
  • changes the other nonce part when the 1= 2 bytes internal nonce is back to 0.
As explained in th= e Crypto++ issue about this, I'm not a fan of the =22key=22 nonce increme= nt, as this is dangerous. This is described as a =22wild memory write=22 in the Crypto++ issue.  =46or example if anyone is using a prev= ious used nonce set and this new incremented nonce will be unknown by the= system, so it can reuse the same nonce as the one incremented. The risk = is very low, since the nonce has an extended size, it is hard to track se= t of used nonce, and mostly used with a random generator. One can also ju= st use incremented nonce as a method to prevent nonce reuse, and this aut= omatic increment will screw everything up with very large files.

We would be grateful if the current IET=46 proposal could be updated wit= h some details about this matter. Whatever the choice, distinctive and cl= ear instructions are better that nothing, else this leads to implementati= ons divergence, as this is already the case for existing affiliated stand= ards. Any limitations or clarification are welcome, else people are doing= =22free=22 things which can be dangerous in terms of security. We thank = you for your effort and time into standardising this, let us know your op= inion.

<= font style=3D=22font-family:Nylas-Pro, Helvetica, "Lucidia Grande&qu= ot;, sans-serif=22>Regards,
=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Antoine =46ERRON
Pr=C3=A9si= dent =E2=80=94 BitLogiK

= bitlogik.fr =E2=80=94 PGP Key ID=2322=4695B31

<= /div>
--6012f279_0_e30f6965--