Attacks on non-personalized hashes

gistfile1.txt

yescrypt pre- and post-hashing
http://thread.gmane.org/gmane.comp.security.phc/1271/focus=2370

Example of 3rd attack described there:

User has a passpharse P. In one protocol, to derive key from
this passphrase, BLAKE2s is used. The hashed passphrase
is then sent to some server.

  P — user's passphrase
  dk0 = BLAKE2s(P)

User then uses the same passpharse to derive miniLock keys:

  publicKey, privateKey = miniLock_deriveKey(P)

Turns out the server that has "dk" from the first computation
can also derive those keys and open things sent to this miniLock
user, because key derivation in miniLock is as follows:
	
	miniLock_deriveKey = 
		1. dk1 = BLAKE2s(P)
		2. scrypt(dk1, ...)
		...

The server that has "dk" skips the first step and just feeds
dk0 to scrypt, because:

	dk0 = dk1
	BLAKE2s(P) = BLAKE2s(P)


This wouldn't happen if at least one protocol personalized hashes:

        BLAKE2s(person="miniLock", P) != BLAKE2s(P)
	BLAKE2s(P) != BLAKE2s(person="server hashing", P)


Some other attack scenarious referenced in Skein paper:

Protocol Interactions and the Chosen Protocol Attack
https://www.schneier.com/cryptography/paperfiles/paper-chosen-protocol.pdf


A Cryptographic Evaluation of IPsec (5.4 Parsing a String of Bytes)
https://www.schneier.com/cryptography/paperfiles/paper-ipsec.pdf

See also: https://en.wikipedia.org/wiki/Horton_Principle


NOTE: The worst thing is that in many case you never know if your protocol
is vulnerable or will be vulnerable in the future, because you don't know
how the same data will be used by another procotol that you didn't design.
Thus, it makes sense to always personalize hashes, which makes such attacks
impossible.