make server send challenge envelope to client like the latest spec says

[david415]

in the latest version of the spec the sever sends the client a challenge where the hmac is keyed with the K concatenated with scalar_mult(a, b) whereas your code only keys the hmac with the applicaton key.

(actually it is the hash of this concatenation but i'll open a separate ticket for the spec.)

[dominictarr]

yeah, this is correct. the paper says that Bob's (the server's) first reply is b_p, Hmac[K|a*b](b_p)

This was pointed out before - but I was reluctant to change it since it didn't have security implications, and also changing things was hard. However, now ssb (which is the biggest application of this) uses has a way of expressing any protocol (via https://github.com/dominictarr/multiserver) changing this thing would be possible, and also upgrading over such a small thing would show that upgrades are possible. (see https://github.com/dominictarr/multiserver#motivation)

hmm, if the stateless methods are passed into the handshake... then we can support the legacy version (for a while) but make the new version be the default.

[AljoschaMeyer]

What is the current state of this, and what does this mean for implementors in another language? Should a new implementation:

• copy the existing (non-spec-conforming) implementation?
• implement the correct (per the spec) behavior?
• implement both and have the api consumer decide which to use?
• implement both and release as different packages?
• implement both and release as different major versions of the same package?

[dominictarr]

If you are writing this to be a ssb implementation, then you'll need to copy the reference implementation. It's a fuckup, but it doesn't have any real security implications. We'll eventually upgrade to a version that fixes this, but there are higher development priorities currently.

[dominictarr]

that said, if someone was to make the PRs for ssb to migrate protocols, I'd be very happy to merge!

[AljoschaMeyer]

A crypto-newbie question regarding this: when the paper refers to a · b, how do I know which of these to compute:

• a.private · b.private
• a.public · b.private
• a.private · b.public
• a.public · b.public

[dominictarr]

@AljoschaMeyer a.public · b.private or a.private · b.public. these produce the same value. you won't have both private keys, so use the private key you do have (i.e. your private key) and the other peer's public key.

[AljoschaMeyer]

Since fixing this requires a new major version of the protocol, I'm hijacking this issue to point out a few more things that could be changed in a major version bump:

• the implementation uses sha256 for hashing whereas sodium recommends BLAKE2b, which also outputs 32 bytes (by default)
• the paper uses H = A_p | sign(A)[K | Bp | hash(a * b)], implementations use H = sign(A)[K | Bp | hash(a * b)] | A_p (i.e. append the public key instead of prepending it)
• box(K | a * b | a * B)[H] always uses 0 as nonce, why not e.g. first 24 bytes of the appkey

What would need to happen to update to shs2? I'm coming up with this list, but I'm probably missing something.

• write a spec
• ask people to review it
• implement shs2 in js
• set new ssb appkey and use multiserver to support both shs1 and shs2 in parallel
• set a deadline after which support for shs1 is removed

[dominictarr]

currently, pubs addresses are with a pub message containing {key, host, port} this needs which only implies shs. This needs to be upgraded to use https://github.com/ssbc/multiserver format addresses. same with local address broadcasts. they are already supported in invite codes. Then just add another multiserver plugin that provides shs2.

[snej]

I’m implementing the algorithm currently, for a new non-SSB protocol. So I could implement the server challenge the “right” way.

However, I'm wondering what makes the challenge in the paper better than the one SSB uses, since according to the above discussion it’s not more secure, and it’s somewhat more complex to implement.