[Cryptography] Best AES candidate broken

[Ryan Carboni]

On Sun, Jul 5, 2015 at 10:47 AM, Tony Arcieri <bascule at gmail.com> wrote:

> On Sat, Jul 4, 2015 at 10:34 PM, Ryan Carboni <ryacko at gmail.com> wrote:
>
>> Except there's one problem with that assertion... Rijndael is easily
>> broken by.... cache timing, differential power, and many other attacks. The
>> knowledge that those attacks could be used certainly was known during the
>> AES competition. [relevant page from Serpent submission attached, will show
>> up in the Metzdowd archives]
>>
>
> Cache timing and DPA can be applied to any implementation of any cipher,
> period.
>
> Serpent in particular uses S-boxes just like AES (or for that matter,
> Lucifer/DES), which makes it just as difficult to implement in software
> with secret independent timing (note: you brought up cache timing, so
> please don't deflect this argument by changing the subject to hardware)
>
> The real solution to cache timing attacks is to eliminate those
> secret-dependent table lookups entirely, as seen in e.g. Salsa20 / ChaCha20.
>
> You might want to take off those rose colored glasses and start paying
> attention to modern cryptography. Things have moved on quite a bit since
> the 90s.
>
> --
> Tony Arcieri
>


Yes, things have moved on since.... what was the release date of IDEA?
1991? Yes, things have moved on since 1991, ciphers have gotten more
advanced with the addition of S-boxes.  No wait, S-boxes in electronic
ciphers were first pioneered in 1977 with DES. But then most of the ciphers
in the AES competition used s-boxes. I don't know if we are moving forwards
or backwards anymore!

Actually the AES S-boxes are secure. As long you don't combine the steps to
create a 256*32 S-box. Modular addition has an issue though, high latency
given that it is a serialized operation. S-boxes are more easily
parallelized.

But I'm just repeating things I've read. What are PhDs supposed to be
anyway, contributors to their field of study?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150705/3f398c68/attachment.html>