[Cryptography] [cryptography] NIST Workshop on Elliptic Curve Cryptography Standards

[Ryan Carboni]

On Tue, May 12, 2015 at 1:19 AM, <dj at deadhat.com> wrote:

>
> > On the lightweight side, I get the impression that block ciphers are
> > also a big topic, but that there isn't a ton of work being done
> > there... besides the NSA ciphers, SIMON and SPECK. John Kelsey
> > mentioned these at RWC. The NSA came to NIST and said "Check out these
> > ciphers!" and NIST said "Those look cool, but please publish them for
> > academic review so we're not favoring you in any way."  So they did.
> > But now the onus is on the community to analyze them and either poke
> > holes in them or present something better.
> >
> > -tom
> >
>
> Simon and speck have had quite a few cryptanalyses published and time has
> passed. Simon is a lovely thing to implement in hardware. It goes up to
> 256,128 key and data size as is more efficient than AES in that
> configuration by about a factor of 3 in hardware for the same performance.
>
> If you don't read ISO specs for amusement (I can't blame you, they charge
> money) PRESENT and CLEFIA are approved lightweight ciphers in ISO. But
> they aren't as lightweight as Simon.
>
> So all other things being equal, it seems to have something over PRESENT,
> CLEFIA and AES. But all other things are not equal. The parentage is
> unfortunate, because as an implementor, I really want Simon to make it
> into the standards space, enabling us to deploy it in products where
> standards compliance is mandatory.
>
> My request to Doug Shors (who was at SC27 last week promoting Simon and
> Speck for WG2) was - Add the missing 256 bit block size. It's the same
> Achilles heel that AES has. The maximum block size is too small. The idea
> that there is a need for lightweight crypto has poisoned the design of
> lightweight ciphers. They are efficient ciphers, whether with small or big
> key sizes or small or big block sizes. The more tasteful ones are smoothly
> scalable in terms of width, unrolling and pipelining. But when they stop
> at 64 bit block sizes or 128 bit key sizes, they limit the deployability
> and performance limits.
>
> David
>
>
>
>
> _______________________________________________
> cryptography mailing list
> cryptography at randombit.net
> http://lists.randombit.net/mailman/listinfo/cryptography
>


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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150512/12518588/attachment.html>