Closed gmaclennan closed 4 years ago
I think the sodium documentation might just be a bit confusing here with the term "very likely".
Having implemented blake2b myself in wasm, the only thing the key argument does in practice is set a flag in the hash state and then call hash.update with the key payload
Ie. hash(key, buffer) ~== hash(concat(key, buffer) + A FLAG) See https://github.com/mafintosh/blake2b-wasm/blob/master/index.js#L62
We set the public key as the key argument as that's the argument with the most entropi meaning an attacker has to mine more to try and break it.
ok got it, so since the hash is just pretty much concat(key, buffer)
it doesn't really make a difference which is which, apart from key
being limited to crypto_generichash_KEYBYTES_MAX
whilst buffer can be arbitrary length.
Yep, I just asked the sodium maintainer on Twitter about the docs phrasing. Will update here if/when he replies.
Frank confirmed https://twitter.com/mafintosh/status/1194621010999332865
sodium.crypto_generichash
expects aninput
buffer of arbitrary length and an optionalkey
. According to sodium docs theinput
is hashed, and the optionalkey
"can be used to make sure that different applications generate different fingerprints even if they process the same data." and different keys "are very likely to produce distinct fingerprints". This "very likely" seems to suggest that this is not as reliable as a hash.The sodium-native docs say the
input
is the second arg, andkey
is the third arg, howeverdiscoveryKey
seems to call the arguments in the wrong order:As far as I understand,
HYPERCORE
should be thekey
. I understand from #3 thattree
is actually thepublicKey
. The consequence of this (I think, although I don't know the internals of sodium) is that the hash is not as guaranteed against collisions. It may be that this doesn't matter and changing thekey
is being hashed with the same algorithm as theinput
, but it doesn't seem like this was the intended way for this to work.