Hacker News new | ask | show | jobs
by pbsd 4266 days ago
I don't think this is a fair assessment. There was a lot of concern over implementation issues during SHA-3 and every finalist did have constant-time implementations, usually coming from the design team itself.

The thing with AES and its derivatives is that they make it very easy to prove resistance against cryptanalysis (differential and linear); ARX designs are very hard to analyze exaustively, and bit-oriented designs tend to be slow. Using AES-like constructions provides a middle ground of reasonable performance and provable security (for some value of security).
1 comments
floody-berry 4266 days ago
Grøstl's round 3 specification document mentions 3 'strategies' for constant time implementations: AES-NI, vperm (AVX/XOP/NEON), or bitsliced (which they estimate "only a 50% overhead" for vs tables). Yet almost all of the implementations they provide that are not AES-NI are either table based or horrifically slow. ARM/NEON is the only non-AES-NI platform with a constant time implementation that is sometimes on par with the table based alternative.

Their constant time approach is "assume use of hardware AES instructions, otherwise enjoy a speed hit if you want to be safe".

link
pbsd 4266 days ago
I'm not sure what's your point. Your claim was that constant-time was not a big issue for many people. Maybe it's not. But the Groestl people wrote an entire report on implementation strategies for it [1], specifically mentioning cache-timing issues on the table-based approaches. They clearly took it seriously.

There are many competing requirements when designing a primitive. Groestl's choices were not necessarily wrong, even when treating side-channel attacks as a "big issue". I don't like Groestl, but I get what they were trying to achieve; Keccak did it much better, though.

[1] http://www.groestl.info/groestl-implementation-guide.pdf

link
floody-berry 4266 days ago
Advocating table based implementations that are not secure is not taking it seriously. Providing implementations that are not secure is not taking it seriously. They may have taken it more seriously than had they designed it in 2001, but it clearly wasn't a major issue for them.

I will admit they are less at fault than the CAESAR candidates who insist on re-using AES.

link