<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 1:19 AM,  <span dir="ltr"><<a href="mailto:dj@deadhat.com" target="_blank">dj@deadhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On the lightweight side, I get the impression that block ciphers are<br>
> also a big topic, but that there isn't a ton of work being done<br>
> there... besides the NSA ciphers, SIMON and SPECK. John Kelsey<br>
> mentioned these at RWC. The NSA came to NIST and said "Check out these<br>
> ciphers!" and NIST said "Those look cool, but please publish them for<br>
> academic review so we're not favoring you in any way."  So they did.<br>
> But now the onus is on the community to analyze them and either poke<br>
> holes in them or present something better.<br>
><br>
> -tom<br>
><br>
<br>
</span>Simon and speck have had quite a few cryptanalyses published and time has<br>
passed. Simon is a lovely thing to implement in hardware. It goes up to<br>
256,128 key and data size as is more efficient than AES in that<br>
configuration by about a factor of 3 in hardware for the same performance.<br>
<br>
If you don't read ISO specs for amusement (I can't blame you, they charge<br>
money) PRESENT and CLEFIA are approved lightweight ciphers in ISO. But<br>
they aren't as lightweight as Simon.<br>
<br>
So all other things being equal, it seems to have something over PRESENT,<br>
CLEFIA and AES. But all other things are not equal. The parentage is<br>
unfortunate, because as an implementor, I really want Simon to make it<br>
into the standards space, enabling us to deploy it in products where<br>
standards compliance is mandatory.<br>
<br>
My request to Doug Shors (who was at SC27 last week promoting Simon and<br>
Speck for WG2) was - Add the missing 256 bit block size. It's the same<br>
Achilles heel that AES has. The maximum block size is too small. The idea<br>
that there is a need for lightweight crypto has poisoned the design of<br>
lightweight ciphers. They are efficient ciphers, whether with small or big<br>
key sizes or small or big block sizes. The more tasteful ones are smoothly<br>
scalable in terms of width, unrolling and pipelining. But when they stop<br>
at 64 bit block sizes or 128 bit key sizes, they limit the deployability<br>
and performance limits.<br>
<br>
David<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
_______________________________________________<br>
cryptography mailing list<br>
<a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
<a href="http://lists.randombit.net/mailman/listinfo/cryptography" target="_blank">http://lists.randombit.net/mailman/listinfo/cryptography</a><br>
</div></div></blockquote></div><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">There is a very simple way around this. Block XXTEA introduced a new method of operation, since folks seem to be renaming primitives (someone decided to call Block Cipher Spices "Tweaks") so let's call it Cipher Round Chaining. Basically a simple cryptographic function is turned into a circular feistel array. In the event that people complain this breaks hardware, I just want to remind everyone that much cryptography is done through instruction sets, and making a single call for a round function. It's quite possible that one could achieve the same security of AES CBC in less rounds using Block XXTEA chaining, without the probabilistic risk of plaintext leakage. Block XXTEA also has some nice data integrity properties, so if the first few words were a shared authentification secret, it could be easy to reject encryptions that don't match the secret.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Although for the internet and smart cards, data packets are small enough for 64 bit blocks not to matter as long as you rekey between packets.</div></div>