As the SHA-3 process went on, I became more attached to Keccak over Skein. Not only is Keccak the direct successor to RadioGatun, the algorithm Deadwood uses for secure random numbers, but also Skein runs like a dog on anything besides a 64-bit CPU.
Indeed, back in 2010, I expressed my preference for Keccak over Skein:
If I were to use one of the SHA-3 submissions for Deadwood’s PRNG, I would use Keccak. Like Skein, it can output a stream of infinite length from any input of any length. Unlike Skein, it is more 32-bit compatible; not only is there a 32-bit “reduced word length” variant officially blessed by the algorithm’s creators, but also 64-bit Keccak more easily scales down to 32-bits than Skein, since the only operations done are permutes, rotates, and exclusive ORs.
When the SHA-3 process was started, there were fears that SHA-2 would fall just like MD5 fell. Fortunately, no significant cryptographic attacks have been mounted against SHA-2. Coupled with the fact that none of the SHA-3 finalists have significantly better software performance than SHA-2, it was logical to choose the one algorithm which is head and shoulders faster than SHA-2 in hardware: Keccak.
While some of other SHA-3 finalists have better software performance than Keccak (Blake is remarkably fast, for example), Keccak still has good software performance. Until dedicated instructions for Keccak are added to CPUs, a sure thing in light of the widespread AES instruction support, applications where software performance is critical can continue to use SHA-2.
Since none of the SHA-3 finalists had better hardware and software performance than SHA-2, it made sense to choose the one algorithm that runs far better on dedicated hardware.
In order to reduce spam, comments for this entry are now closed