[floody-berry]

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".

[pbsd]

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

[floody-berry]

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.