<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Mar 28, 2016 at 8:00 AM, Phillip Hallam-Baker <span dir="ltr"><<a href="mailto:phill@hallambaker.com" target="_blank">phill@hallambaker.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Today we have a very different situation. AES has found its way into<br>
many crypto suites as a set of instructions for executing a round. And<br>
that is to be expected in an era where one of the chief problem of CPU<br>
design is to find a useful way to spend the available gates.<br>
<br>
So now we have a cipher designed for efficient software implementation<br>
being migrated into the hardware. Which sounds like a big deal except<br>
that what is really happening is that the software has moved from<br>
executable code to microcode.</blockquote><div><br></div><div>Did you just make the claim:</div><div><br></div><div>"So now we have a cipher designed for efficient software implementation being migrated into the hardware." </div></div><div class="gmail_extra"><br></div>...about AES?</div><div class="gmail_extra"><br></div><div class="gmail_extra">This is patently untrue: AES was designed for efficient hardware implementations, and implementing it *correctly* in software is incredibly difficult:</div><div class="gmail_extra"><br></div><div class="gmail_extra"><a href="https://cr.yp.to/mac/variability1.html">https://cr.yp.to/mac/variability1.html</a></div><div class="gmail_extra"><br></div><div class="gmail_extra">By contrast, other AES candidates like Serpent were designed with techniques like bitslicing in mind, making them more amenable to software implementations.<br clear="all"><div><br></div>-- <br><div class="gmail_signature">Tony Arcieri<br></div>
</div></div>