On 23 Dec 2015 7:20 am, "Ben Harris" <<a href="mailto:mail@bharr.is">mail@bharr.is</a>> wrote: > > On 22 Dec 2015 10:40 pm, "Max Skibinsky" <<a href="mailto:max@skibinsky.com">max@skibinsky.com</a>> wrote: > > > > > 5) Why use encryption of a secret as the ZKP of a_comm_pk? A signature would be the more conventional route. > > > > That is indeed a gnarly part, good catch. Main reason is the limit of > > a library we had to work with. Nacl uses different key formats for > > encryption (crypto_box) and signatures (crypto_sign). We based our web > > stack on nacl-js, which doesn’t yet support for conversion between > > these 2 types. So the judgment call was to either create > > unproven/untested code that will do sophisticated key converstion, or > > accept slightly bizzare structuring of the protocol, but keep all > > execution paths 100% within proven nacl functions. The latter seemed > > like significantly less risky choice. > > Yes, good point. It would still be more idiomatic to use a HMAC instead of the encryption. You use the same key in both. Actually, upon reading this again the real issue is that you are trying to use the same key pair for encryption and authentication. Don't do that, the HPK should be based on a signing keypair (Ed25519). If you want to bootstrap an encryption session (curve25519 keypair or axolotl) just send the encryption keypair signed by the authentication keypair.