hash function implied but not specified in secret-handshake spec

[david415]

in the latest version of the spec the server to client challenge keys the hmac with K concatenated with scalar_mult(a,b) whereas it should be the hash of the concatenation.

similarly the shared secrets for the two box operations are produced by concatenation and then hashing whereas the spec does not specify the hash function here either.

[dominictarr]

all algorithms are those provided by nacl. though we obviously need to be clearer about the hash, because that is the one thing that nacl provides several of.

[dominictarr]

on that note, the paper is intended to explain the reasoning behind the design of the protocol, maybe there should be a separate document for implementers which is just about the exact algorithms and byte lengths, with pseudocode and test vectors

[david415]

consider switching to blake2b as the hash function because it's super fast.

[dominictarr]

That is correct, but it doesn't make much difference because perf is dominated by asymmetric operations. A single scalarmult is worth about 180 sha256(32bytes)'s https://github.com/dominictarr/sodiumperf/blob/master/results/bindings.txt since we are only hashing small things, and have lots of asymmetric ops, using a really fast hash would be unlikely to make a measurable difference.

Though, I do think blake2b is cool, and I would totally use it in an application where hash performance over sha2/3 made a measurable difference.