[messaging] RFC: async NaCl relay

[Ben Harris]

On 22 Dec 2015 10:40 pm, "Max Skibinsky" <max at skibinsky.com> wrote:
>
> double check. I assume server verification function you meant should
> be something like concat(nonce, timestamp, verify_token, HMAC(
> concat(nonce, timestamp, verify_token)) ? difficulty is constant
> value, so it doesn’t add much to verification. what needs to be
> verified is POW nonce joining recent timestamp with given
> verify_token. Relay still will need to cache verify_token while
> handshake is in progress, yet that’s one token less than current
> footprint.

No, include the difficulty in the token and HMAC. And the server shouldn't
need to store anything, when it receives the token back it uses the HMAC to
ensure that the token was issued by the server.

> One potential issue (need to think more): now POW will be dependent on
> timestamp (which can *not* be removed in this case; contrast with
> current ver where client_token plays the role of static id of client
> request) - at some difficulty setting weaker clients may not finish
> POW in time to complete the handshake.

Just allow the token to last long enough, you just need to increase the
size of the "used token" list to compensate.

>
> If I understand correctly what you are suggesting:
> - create long-term identity for relay itself
> - let no-TLS relay owners use that identity to verify their own
> self-deployed relay?
> - first message from relay will be effectively an "advertisement" of
> that self-made cert?

No, just have a static c25519 keypair on the relay r_lt_sk, r_lt_pk. When
generating the session key the client does DH with both r_lt_pk and
r_sess_pk and includes both into the hash. Client also ensures r_lt_pk
hasn't changed since last time. You also then need to handle cases where
server updates long term keys.

Alternatively, just fully trust TLS and make that explicit. This is
probably the better route.

>
> > 3) What is the reason to use H2 instead of just a single hash iteration?
>
> afaik double hashing was created as protection against length
> extension attacks. Ferguson & Schneier first suggested Hdbl(m) =
> h(h(m) || m) in [1]. Yevgeniy had been researching security of such
> constructs in [2] - they analyzed and proved that sha256(sha256( 0^32
> || msg)) has strong security, so we followed his recommendation.

I'm not sure you care about length extension for much of this (you aren't
doing any keyed hashes). And for the parts you would (i.e. HMAC
constructions), NACL has a proper HMAC implementation.

> > 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.

> endpoint _without_ its own HPK, but who can message another HPK? Any
> specific use cases for such “send only” clients? I’m a bit warry about
> allowing this: if they don’t have own HPK, they are effecitively
> becoming unlimited “anon” users, and zax can not verify anything about
> them before accepting communications. Maybe you have specific use
> cases in mind that would allow to make requirements a bit tighter and
> avoid wide open case of “any anon” => HPK communications?

Anyone can generate a new keypair and HPK, so you allow anon anyway. I was
suggesting that since you treat the payload as an opaque blob you may have
the option of a small send-only device that just uses, e.g. symmetric key
encryption for messages. It would then just add complexity to force it to
handle asymmetric crypto just to send a message.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20151223/28477f4c/attachment.html>