The idea that you could slash SHA-3 from 24 rounds to 10 (2.4x faster) and get the same effective security is astounding. I assume that applies just as much to using Keccak for encryption as hashing?
SHA-3 was finished in the aftermath of Snowden's revelations, and NIST's credibility was very low at the time, they needed to be extra conservative about security margins for this reason.
> SHA-3 was finished in the aftermath of Snowden's revelations, and NIST's credibility was very low at the time, they needed to be extra conservative about security margins for this reason.
Yep. There was discussion about this among NIST, the Keccak team, and the other cryptographers contributing to SHA-3. The consensus was that because NIST had been involved in the Dual_EC_DRBG backdoor, that their credibility was dangerously low and that they couldn’t standardize anything that ill-informed people could misconstrue as “weakening” SHA-3, even if the actual cryptographers involved thought it would still be secure. So in one sense, you can chalk up the unnecessary computational cost of SHA-3 as collateral damage from the Dual_EC_DRBG backdoor.
Kravatte (briefly mentioned in the paper), Keyak, and Ketje (all using the keccak permutation) do use fewer rounds than SHA-3, e.g. 12 in the case of Keyak.
The paper is describing what cryptographers have been doing the past 5ish years at least (see various CAESAR contest entries, the forms of Masked Even-Mansour that use 4 or 6 rounds of BLAKE2b permutation, etc.), but maybe encouraging them to push more in that direction.
