[147002] in cryptography@c2.net mail archive
Re: [Cryptography] Evaluating draft-agl-tls-chacha20poly1305
daemon@ATHENA.MIT.EDU (Alexandre Anzala-Yamajako)
Wed Sep 11 12:34:00 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <522FDC79.7090204@gmail.com>
From: Alexandre Anzala-Yamajako <anzalaya@gmail.com>
Date: Wed, 11 Sep 2013 12:00:40 +0200
To: William Allen Simpson <william.allen.simpson@gmail.com>
Cc: "cryptography@metzdowd.com" <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============8223004126802773513==
Content-Type: multipart/alternative; boundary=089e013a274600742904e618b422
--089e013a274600742904e618b422
Content-Type: text/plain; charset=ISO-8859-1
2013/9/11 William Allen Simpson <william.allen.simpson@gmail.com>
> It bugs me that so many of the input words are mostly zero. Using the
> TLS Sequence Number for the nonce is certainly going to be mostly zero
> bits. And the block counter is almost all zero bits, as you note,
>
> (In the case of the TLS, limits on the plaintext size mean that the
> first counter word will never overflow in practice.)
>
> [...]
>
> In my PPP ChaCha variant of this that I started several months ago, the
> nonce input words were replaced with my usual CBCS formulation. That is,
> invert the lower 32-bits of the sequence number,
> xor with the upper 32-bits,
> add (mod 2**64) both with a 64-bit secret IV,
> count the bits, and
> variably rotate.
> [...]
>
Chacha20 being a stream cipher, the only requirement we have on the ICV is
that it doesn't repeat isn't ?
This means that if there's a problem with setting 'mostly zeroed out' ICV
for Chacha20 we shouldn't use it at all period.
As far as your proposition is concerned, the performance penalty seems to
largely depend on the target platform. Wouldn't using the same set of
operations as Chacha prevent an unexpected performance drop in case of lots
of short messages ?
Cheers
--089e013a274600742904e618b422
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">2013/9/11 William Allen Simpson <span dir=3D"ltr"><<a href=3D"ma=
ilto:william.allen.simpson@gmail.com" target=3D"_blank">william.allen.simps=
on@gmail.com</a>></span><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">It bugs me that so many of the input words a=
re mostly zero. =A0Using the<br>
TLS Sequence Number for the nonce is certainly going to be mostly zero<br>
bits. =A0And the block counter is almost all zero bits, as you note,<br>
<br>
=A0 =A0(In the case of the TLS, limits on the plaintext size mean that the<=
br>
=A0 =A0first counter word will never overflow in practice.)<br>
<br>
[...]<br></blockquote><div>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In my PPP ChaCha variant of this that I started several months ago, the<br>
nonce input words were replaced with my usual CBCS formulation. =A0That is,=
<br>
=A0 =A0invert the lower 32-bits of the sequence number,<br>
=A0 =A0xor with the upper 32-bits,<br>
=A0 =A0add (mod 2**64) both with a 64-bit secret IV,<br>
=A0 =A0count the bits, and<br>
=A0 =A0variably rotate.<br>
[...]<br></blockquote><div><br></div><div>Chacha20 being=A0 a stream cipher=
, the only requirement we have on the ICV is that it doesn't repeat isn=
't ?<br></div><div>This means that if there's a problem with settin=
g 'mostly zeroed out' ICV for Chacha20 we shouldn't use it at a=
ll period.<br>
</div><div>As far as your proposition is concerned, the performance penalty=
seems to largely depend on the target platform. Wouldn't using the sam=
e set of operations as Chacha prevent an unexpected performance drop in cas=
e of lots of short messages ?<br>
<br></div><div>Cheers<br></div><div><br></div></div></div></div>
--089e013a274600742904e618b422--
--===============8223004126802773513==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============8223004126802773513==--
