One can always turn any hash function into a cipher or rng or vice versa. That’s not surprising.
Keccak (aka the algorithm that became sha-3) is also explicitly advertised as being flexible for other use cases. Two keccak-based authenticated encryption modes are part of the CAESAR competition.
There’s a lot of existing sha1-deployment, and so the exact same argument might keep them there for a long while.
I really think the sponge construction will pay dividends: shaking out an arbitrary number of bits without bias makes bloom filters faster; saves time and memory with your DHT, makes a better HLL, obviates hmac, and so on. I think the only real danger comes from implementing and popularizing sha3_256(data,length) instead of what we’ve really got here…
The argument for SHA-2 is that SHA-1 has already been found to be vulnerable to collisions, which will only get cheaper over time, the same way MD5 collisions have.
SHA-2 and SHA-3 are both safe (currently) from collisions. The author points out that it’s not necessarily clear SHA-3 is stronger or more safe than SHA-2.
I understand what the author’s point is, but mine is that I’m unconvinced: Collisions aren’t everything.
HMAC and padding are unsatisfying and the fact that SHA3/SHAKE doesn’t appear to need either is valuable to me, and I suspect valuable to others if they stop treating crypto as a black-box.
[Comment removed by author]
Can you give an example? I’m not certain that I understand what you mean.
[Comment removed by author]
One can always turn any hash function into a cipher or rng or vice versa. That’s not surprising.
Keccak (aka the algorithm that became sha-3) is also explicitly advertised as being flexible for other use cases. Two keccak-based authenticated encryption modes are part of the CAESAR competition.
Maybe skip SHA-2?
There’s a lot of existing sha1-deployment, and so the exact same argument might keep them there for a long while.
I really think the sponge construction will pay dividends: shaking out an arbitrary number of bits without bias makes bloom filters faster; saves time and memory with your DHT, makes a better HLL, obviates hmac, and so on. I think the only real danger comes from implementing and popularizing
sha3_256(data,length)instead of what we’ve really got here…The argument for SHA-2 is that SHA-1 has already been found to be vulnerable to collisions, which will only get cheaper over time, the same way MD5 collisions have.
SHA-2 and SHA-3 are both safe (currently) from collisions. The author points out that it’s not necessarily clear SHA-3 is stronger or more safe than SHA-2.
I understand what the author’s point is, but mine is that I’m unconvinced: Collisions aren’t everything.
HMAC and padding are unsatisfying and the fact that SHA3/SHAKE doesn’t appear to need either is valuable to me, and I suspect valuable to others if they stop treating crypto as a black-box.