[noise] Noise replacements for crypto_box and crypto_secretbox

[Trevor Perrin]

On Sun, Oct 2, 2016 at 10:55 PM, Brian Smith <brian at briansmith.org> wrote:
> Trevor Perrin <trevp at trevp.net> wrote:
>>
>> crypto_secretbox_xsalsa20poly1305 is interesting because it supports a
>> 24 byte nonce, which is large enough to be randomly generated without
>> fear of collisions.  To support that, it uses a hash function derived
>> from Salsa20 to hash the key and the nonce into a new key.
>
>
> This is the key point that needs to be addressed: What should the standard
> construction be in Noise for the situation where one cannot maintain state
> between invocations of crypto_box-like Noise protocol? maybe we could define
> an XChaCha20-Poly1305 like function exactly analogous to XSalsa20, or use
> HKDF like you suggest below, or prescribe a full nonce-misuse-resistant
> scheme.

There's a few different things here, to separate them a bit:

 * Large nonce support (like XSalsa20) is different from
"nonce-misuse-resistance" (like SIV), though you could do both.

 * Noise hasn't needed AEAD with large nonces, because it uses
ephemeral DH and HKDF to generate unique cipher keys during the
handshake phase, and assumes the transport phase is stateful.  So it's
been designed to make minimal assumptions on AEAD nonce size (64 bits
counter), for maximum compatibility with different ciphers.

 * To hedge against RNG repetition, Noise could use
nonce-misuse-resistant AEAD like any other AEAD (e.g. "AESGCMSIV"
instead of "AESGCM").

It's possible that large-nonce AEAD (or just AE) is a useful construct
in itself.  I guess it's also possible that a Noise handshake could be
followed by a transport phase that can't maintain state, but that
seems unusual.

Having some use cases for large-nonce AEAD would help ground the discussion.


> Tradeoffs:
>
> (1) XChaCha20-Poly1305 has two advantages: Most crypto libraries can add it
> right now with little to no effort, and it is exactly what NaCl does, except
> swapping Sals20 for ChaCha20. The disadvantage is that it isn't fully
> nonce-misuse-resistant.

So you want something like crypto_secretbox but with XChaCha20 and
SIV?  You could probably design that, and name it like:

crypto_secretbox_xchacha20poly1305siv

That would be fine, though wouldn't have much connection to Noise.


> (2) The HKDF scheme: It doesn't require changes to any crypto protocols that
> otherwise can already implement Noise. Disadvantage: Requires more
> explanation to convince NaCl users that it is as good or better than the
> NaCl construction.
[...]
> Deriving a new key every time seems like it would be painful w.r.t.
> performance, at least for AES.

HKDF is not hard to justify, security-wise, and the advantage is that
it avoids extra requirements or custom design for each cipher.

OTOH, maybe you're happy turning ChaCha20 into XChaCha20.

I guess GCM can natively support larger nonces (in theory, though I'm
not sure if support for that is common?).  And GCM with large nonces
doesn't change the cipher key (to your last point).  I'm not sure how
much that would matter, but maybe.


> If the goal is to have a Noise analog to what NaCl does, then it seems
> reasonable to have it only work (well) for ChaCha20.

I'd prefer to keep Noise as a framework that can be instantiated with
a wide range of crypto, as much as possible.


> Personally, I'm looking for an X that allows me to say "I don't have exactly
> that, but you can use X instead, which is better because it doesn't require
> *ring* to implement XSalsa20 and...." when people ask me to implement NaCl
> equivalents in my library.

If they have an existing NaCl protocol, they're going to need NaCl exactly.


> More generally, Noise offers too many choices for people to switch from
> advising "Just use NaCl" to "Just use Noise". OTOH, it might be worth
> reviewing the specifics of well-known protocols that have taken the "Just
> use NaCl" advice, like Macaroons, to see if the advice was as good as it
> initially seemed.

I would say "Just use Noise_X" for one-way messages, or Noise Pipes
for an interactive protocol.  If you realize you don't need everything
they do, you can switch to a simpler pattern.

The original Macaroons just used HMAC, I think?  I thought Tony was
talking about some extension that just used AEAD, not the DH crypto
boxes.

I don't have a good sense of where DH crypto_boxes are most used, so
I'm not sure what advice I'd give them.


Trevor