[messaging] saltpack spec and library

[Mike Hearn]

This looks really interesting Jack.

A few quick questions:

1) Why MessagePack vs other binary serialisation formats?  (i tend to use
protobufs)

2) When staying in binary, what sort of overhead does the format impose?

3) If you imagine a mix network for routing of small binary messages, is
saltpack an appropriate format to use for protecting the messages in your
estimation? Or are there gotchas that its replacement-for-pgp design would
create for the case of pure machine-to-machine messaging?

4) MIME type? Could you maybe forbid/strongly discourage in the spec emails
that contain ASCII armoured saltpack messages? I think some clients have
struggled in the past with the UI for showing a message that contains
partially signed and partially not signed text, as they tend to treat the
signedness of a message as a boolean. Formally forbidding mixing of the two
can solve that.

5) The format appears to be at least partly defined through unversioned
reference to a particular library (NaCL). In particular it does not specify
what a "NaCL public key" actually is (curve25519 presumably). That seems
like it should be fixed for a realistic spec.

6) It'd be nice if there was a way to embed X.509 cert chains (i.e. signed
curve25519 certificate) into the headers, to allow the sender to
authenticate themselves with a PKI instead of Keybase. Then it could act as
a competitor to CMS.

thanks,
-mike

On Fri, Feb 5, 2016 at 6:30 AM, Jack O'Connor <oconnor663 at gmail.com> wrote:

> > I don't think that's right.  If an attacker creates a new ephemeral,
> > they won't be able to encrypt the original payload key.  All they'd
> > accomplish is forging a message that decrypts to gibberish.
>
> Oops, you're totally right.
>
> Thanks for letting us steal so much of your time, Trevor. If you're
> ever near the Keybase office in SF or NYC, we owe you a beer!
>
> - Jack
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20160209/f93f684f/attachment.html>