[messaging] RFC: async NaCl relay

Ben Harris mail at bharr.is
Sun Dec 20 17:25:28 PST 2015

On 20 December 2015 at 10:11, Max Skibinsky <max at skibinsky.com> wrote:

> Our design constraints are different, so zax is build around different
> architecture. When there is no gossip between nodes, no mutual discovery,
> no pre-registration, no "central" relays - all this eliminates most of the
> issues you mentioned and greatly simplifies the codebase. Relay becomes
> very lightweight, can even be run even on Raspberry (one of the properties
> we wanted). Address space is global between all relays: clients can leave
> messages to anybody on any relay. Node discovery moves to the client layer.
> Any device can prove "ownership" of HPK to a relay, and collect traffic (if
> any) for itself from that relay: it's up to a device to make sure it
> checked all relays it expects traffic at. Naturally, all that at the cost
> of creating different tradeoffs: for example delivery becomes unreliable
> with bigger task load for the client device.
> Overall, apps using these relays should be agonistic about providers of
> the relays: some of can be app vendors, some can be power users themselves.
> App do not need to know all relays in the network, just large enough number
> to have high degree of confidence that messages (duplicated across relays)
> do reach their intended destination.

This is great Max, thanks for sharing.

Couple of comments:

1) I'd suggest simplifying the first two interactions to the following (to
minimise stored state on the server)
Alice does a GET to /sessions and receives {difficulty, verify_token}
Alice does POST to /sessions/[verify_token] with diff_nonce if needed, and
receives r_sess_pk

In this situation, the client treats verify_token as an opaque byte array.
On the server it will probably be implemented as concat(nonce, timestamp,
difficulty, HMAC( concat(nonce, timestamp, difficulty) ). The server then
just verifies the token is current, difficulty matches, MAC is correct, and
it has not already been used.

This means the server doesn't store any state until after the difficulty
requirement is met.

2) All of the encryption work in the second phase seems to imply you don't
trust the TLS layer? Otherwise you would just send messages signed by the
a_comm_pk to the server. If you really don't trust the TLS layer, you need
to have the relay send a long term public key in the first message, and the
client should store it and use it in key derivation (TOFU style).

3) What is the reason to use H2 instead of just a single hash iteration?

4) What is the reason to use the hash of the public key as the address?

5) Why use encryption of a secret as the ZKP of a_comm_pk? A signature
would be the more conventional route.

6) I'd suggest considering also being able to use verify_token from 1 above
in the upload command (maybe as a 'fast upload' command). It simplifies
dumb send-only clients (don't have an HPK, may not need asymmetric crypto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151221/6a3df67c/attachment.html>

More information about the Messaging mailing list