Re: RFC v3: Another proposed hash function transition plan

On 13 September 2017 at 14:05, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

FWIW, and I know it is not worth much, as far as I can tell there is at least some security/math basis to prefer SHA3-256 to SHA-256.

The SHA1 and SHA-256 hash functions, (iirc along with their older cousins MD5 and MD2) all have a common design feature where they mix a relatively large block size into a much smaller state *each block*. So for instance SHA-256 mixes a 512 bit block into a 256 bit state with a 2:1 "leverage" between the block being read and the state. In SHA1 this was worse, mixing a 512 bit block into a 160 bit state, closer to 3:1 leverage.

SHA3 however uses a completely different design where it mixes a 1088 bit block into a 1600 bit state, for a leverage of 2:3, and the excess is *preserved between each block*.

Assuming everything else is equal between SHA-256 and SHA3 this difference alone would seem to justify choosing SHA3 over SHA-256. We know that there MUST be collisions when compressing a 512 bit block into a 256 bit space, however one cannot say the same about mixing 1088 bits into a 1600 bit state. The excess state which is not directly modified by the input block makes a big difference when reading the next block.

Of course in both cases we end up compressing the entire source document down to the same number of bits, however SHA3 does that *once*, in finalization only, whereas SHA-256 does it *every* block read. So it seems to me that the opportunity for collisions is *much* higher in SHA-256 than it is in SHA3-256. (Even if they should be vanishingly rare regardless.)

For this reason if I had a vote I would definitely vote SHA3-256, or even for SHA3-512. The latter has an impressive 1:2 leverage between block and state, and much better theoretical security levels.

cheers,
Yves
Note: I am not a cryptographer, although I am probably pretty well
informed as far hobby-hash-function-enthusiasts go.