1. 18
  1.  

  2. [Comment removed by author]

    1. 1

      Can you give an example? I’m not certain that I understand what you mean.

      1. [Comment removed by author]

        1. 6

          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.

    2. 2

      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…

      1. 3

        Maybe skip SHA-2?

        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.

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