<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 25, 2017 at 3:56 PM, D. J. Bernstein <span dir="ltr"><<a href="mailto:djb@cr.yp.to" target="_blank">djb@cr.yp.to</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">A year ago I wrote:<br>
> Concretely, several generations of Intel chips have run 12-round<br>
> ChaCha12-256 at practically the same speed as 12-round AES-192 (with a<br>
> similar security margin), even though AES-192 has "hardware support", a<br>
> smaller key, a smaller block size, and smaller data limits. For example:<br>
><br>
>    * Both ciphers are ~1.7 cycles/byte on Westmere (introduced 2010).<br>
>    * Both ciphers are ~1.5 cycles/byte on Ivy Bridge (introduced 2012).<br>
>    * Both ciphers are ~0.8 cycles/byte on Skylake (introduced 2015).<br>
><br>
> ChaCha20-256 is slower than ChaCha12-256 but this is entirely because it<br>
> has a much larger security margin. For reasons explained below, I<br>
> wouldn't be surprised to see ChaCha20-256 running _faster_ than AES-256<br>
> on future Intel chips.<br>
<br>
Romain Dolbeau has now submitted benchmarks for an Intel Skylake with<br>
AVX-512:<br>
<br>
   * 0.48 cycles/byte: 12-round ChaCha12-256.<br>
   * 0.48 cycles/byte: 12-round Salsa20/12-256.<br>
   * 0.69 cycles/byte: 20-round ChaCha20-256.<br>
   * 0.69 cycles/byte: 20-round Salsa20-256.<br>
   * 0.87 cycles/byte: 14-round AES-256.<br>
<br>
<a href="https://bench.cr.yp.to/results-stream.html#amd64-manny1024" rel="noreferrer" target="_blank">https://bench.cr.yp.to/<wbr>results-stream.html#amd64-<wbr>manny1024</a><br>
<br>
Thanks to Intel for giving up on AES and joining the monoculture! :-)<br>
The code is C code from Dolbeau, using _mm512_rol_epi32() etc.<br></blockquote><div><br></div><div>I've been very curious about these numbers, as ChaCha is an algorithm that seems to fit AVX-512 like a glove.</div><div><br></div><div>That said, I know a lot of people who have operational problems with AVX-heavy workloads, particularly those who are trying to run a mixed AVX-heavy workload which also has various CPU-heavy things.</div><div><br></div><div>I've also gotten a lot of reports from people (but have not personally experienced) thermal throttling on AVX heavy workloads.</div><div><br></div><div>While these numbers seem very impressive, I can only assume the power/heat required to pull them off is substantially higher than the AES workload.</div><div><br></div><div>All that said, I'm very curious how this sort of AVX-heavy workload would interact with your typical messy "business logic"-heavy program as compared to an AES-NI workload.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Meanwhile there's a burst of papers this month from people struggling<br>
with the security limitations of AES:<br>
<br>
   <a href="https://eprint.iacr.org/2017/697" rel="noreferrer" target="_blank">https://eprint.iacr.org/2017/<wbr>697</a><br>
   <a href="https://eprint.iacr.org/2017/702" rel="noreferrer" target="_blank">https://eprint.iacr.org/2017/<wbr>702</a><br>
   <a href="https://eprint.iacr.org/2017/708" rel="noreferrer" target="_blank">https://eprint.iacr.org/2017/<wbr>708</a></blockquote><div><br></div><div>Unless I'm missing something, these papers are all about AES-GCM-SIV and the security limitations that arise from GCM, not AES... <br></div></div><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Tony Arcieri<br></div>
</div></div>