[messaging] RFC: async NaCl relay

Ben Harris mail at bharr.is
Tue Dec 22 13:28:15 PST 2015

On 23 Dec 2015 7:20 am, "Ben Harris" <mail at bharr.is> wrote:
> On 22 Dec 2015 10:40 pm, "Max Skibinsky" <max at skibinsky.com> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151223/1b661cbe/attachment.html>

More information about the Messaging mailing list