<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/9/11 William Allen Simpson <span dir="ltr"><<a href="mailto:william.allen.simpson@gmail.com" target="_blank">william.allen.simpson@gmail.com</a>></span><br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It bugs me that so many of the input words are mostly zero.  Using the<br>
TLS Sequence Number for the nonce is certainly going to be mostly zero<br>
bits.  And the block counter is almost all zero bits, as you note,<br>
<br>
   (In the case of the TLS, limits on the plaintext size mean that the<br>
   first counter word will never overflow in practice.)<br>
<br>
[...]<br></blockquote><div> </div><blockquote class="gmail_quote" style="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.  That is,<br>
   invert the lower 32-bits of the sequence number,<br>
   xor with the upper 32-bits,<br>
   add (mod 2**64) both with a 64-bit secret IV,<br>
   count the bits, and<br>
   variably rotate.<br>
[...]<br></blockquote><div><br></div><div>Chacha20 being  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 setting 'mostly zeroed out' ICV for Chacha20 we shouldn't use it at all 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 same set of operations as Chacha prevent an unexpected performance drop in case of lots of short messages ?<br>

<br></div><div>Cheers<br></div><div><br></div></div></div></div>