Check why sha2 and rmd have broken bad seeds

[rurban]

Could be some padding artefact, leading to excessive collisions. So far avoid rmd and sha2 for hashing like the plague. The logs for testing all the bad seeds excess 500MB, most seeds lead to collisions.

[avaneev]

Isn't SHA2 seed-less? How did you manage to add seed to it?

[avaneev]

The same question applies to SHA3 actually. Is seeding documented?

[rurban]

Blake more than sha3. My current suspect is the tomcrypt library I was using. sha2ni is fine.

I mix the seed with xor to the first iv value, which should be fine.

[Keith-Cancel]

I thought that was curious too. I will add the SHA-2 has some foot guns which is why H-MAC is thing, and here we are using the seed much like a key in H-MAC.

Wikipedia has brief explanation on the rational of H-MAC https://en.wikipedia.org/wiki/HMAC#Design_principles

Anyways, this was one of the reason the SHA-3 competition was held not just to have a hash function that was much different than SHA-2, but to avoid some of the foot guns.

Edit

Blake more than sha3. My current suspect is the tomcrypt library I was using. sha2ni is fine.

I mix the seed with xor to the first iv value, which should be fine.

Oh, hmm that does not sound good for that library then.

[human-0]

I found the problem. The hashes use the global ltc_state, meaning they are not thread-safe. When tested on one thread, the bad seeds go away, at least for the first 0x15ffffff seeds of sha-256. I don't know why this doesn't affect blake2 or sha-3 even though they have the same problem.

[wangyi-fudan]

@human-0 have you tested this on wyhash?

[human-0]

Wyhash still fails with bad seeds. I don't think it has global state.

I also tested sha2-256 more and it seems to pass MomentChi2 when tested single-threaded.

[rurban]

The wyhash bad seeds are an inherent property of all MUM-based hashes

[rurban]

Redoing all those broken tomcrypt BadSeeds tests now. Also the MomentChi2 tests (also threaded and wrong).