<div dir="ltr"><div>To Ray:</div><div> </div><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"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">Rijndael has a proof of security against linear and differential
cryptanalysis.</pre></blockquote><div> </div><div>This uses the same S-box. Thus the security proof has been forked. This essentially replaces the mix columns with a better mixing function, as the AES mix columns appears to have anti-cryptographic properties. Although Rijndael seems vulnerable to Bicliques.</div><div><br></div><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"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">One thing that SIMD ciphers are particularly prone to is
Tempest attacks.  You get a whole lot of processors doing
the same thing at the same time, and they act like a little
phased array of tiny radio transmitting antennas.</pre></blockquote><div><br></div><div>Except that each input is different? It is an interesting challenge to distinctly figure out the internal state of each ALU unit based on emissions, although when many ALU units are simultaneously active, that may make things difficult.</div><div><br></div><div>I'm not capable of addressing your other points. </div><div><br></div><div>-------------------------------------------------</div><div><br></div><div>To <b style="color:rgb(0,0,0);font-family:'Times New Roman';font-size:medium">Alexandre:</b></div><div><b style="color:rgb(0,0,0);font-family:'Times New Roman';font-size:medium"><br></b></div><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"><pre style="white-space:pre-wrap;color:rgb(0,0,0)">This is both heavier and slower than regular AES</pre></blockquote><div><br></div><div><span style="color:rgb(0,0,0);font-size:1em">TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 costs at least one hundred thousand cycles for the key schedule. The key schedule for ciphers in Veracrypt requires around 10</span>,000,000 cycles?</div><div><br></div><div>That's the thing, for big computers, key set-up time is insignificant compared to asymmetric cryptography, or for key stretching. </div><div><br></div><div>For long messages, Nasruddin aims to be fast using modern instruction sets. AESENCLAST has a latency of 6 cycles, but a throughput of 2 cycles. Thus the subbytes step will cost (although the requirement of having a few registers dedicated to a key of zero could cause a cache miss) eight cycles per round.</div><div><br></div><div>Packed addition may take a few cycles per round.</div><div><br></div><div>This might be... two or three cycles per byte?</div><div><br></div><div>In any case, if computers gain a Speck New Instructions set, and if it includes the ability to pipeline multiple Speck encryptions per cycle, than this will be less than a cycle per byte. But such a thing is purely hypothetical. But it seems likely that Speck would be standardized over Simon, considering that Simon is nearly broken and it hasn't even been adopted! It's simple key schedule certainly reduces it's security margin.</div></div>