[noise] Noise replacements for crypto_box and crypto_secretbox

[Brian Smith]

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.

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.

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

(3) Fully nonce-misuse-resistant scheme: The advantage is that it is the
safest option. The disadvantages are that there's no clear standard to
follow, current standardization projects are contentious and far from
completion, and it may be difficult to convince NaCl users to use it.

Noise tries to make minimal assumptions on its underlying crypto
> functions.  So a large-nonce AE in the style of Noise could just use
> HKDF, e.g. with Noise's "HKDF" function:
>
> crypto_secretbox(key, nonce, plaintext)
>   k = HKDF(key, nonce)
>   ENCRYPT(k, n=0, ad=zerolen, plaintext)
>

Deriving a new key every time seems like it would be painful w.r.t.
performance, at least for AES.


> You could adapt the Noise naming convention, e.g.
> I don't know enough about the use cases, though:
>  * Is re-using the same key with random nonces common enough to make
> this worthwhile?
>

This is why I suggested there might not be a 1-to-1 mapping. Noise might
define two constructions, one for when you can maintain nonce state
reliably, and one for when you can't.


>  * If the use cases are low-end devices, then you might prefer a more
> integrated design like XSalsa20.  But then you have to customize it
> for every cipher.
>

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.

Alternatively, we've thought about generalizing Noise Pipes to support
> PSK-based resumption, which can give similar performance, so that
> might be a better option for cases that need extreme speed.
>

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.

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.

Cheers,
Brian
-- 
https://briansmith.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20161002/792b7058/attachment.html>