<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">crypto_secretbox_xsalsa20poly1<wbr>305 is interesting because it supports a<br>
24 byte nonce, which is large enough to be randomly generated without<br>
fear of collisions. To support that, it uses a hash function derived<br>
from Salsa20 to hash the key and the nonce into a new key.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>Tradeoffs:</div><div><br></div><div>(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.</div><div><br></div><div>(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.</div><div><br></div><div>(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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Noise tries to make minimal assumptions on its underlying crypto<br>
functions. So a large-nonce AE in the style of Noise could just use<br>
HKDF, e.g. with Noise's "HKDF" function:<br>
<br>
crypto_secretbox(key, nonce, plaintext)<br>
k = HKDF(key, nonce)<br>
ENCRYPT(k, n=0, ad=zerolen, plaintext)<br></blockquote><div><br></div><div>Deriving a new key every time seems like it would be painful w.r.t. performance, at least for AES.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">You could adapt the Noise naming convention, e.g.<br>I don't know enough about the use cases, though:<br>
* Is re-using the same key with random nonces common enough to make<br>
this worthwhile?<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
* If the use cases are low-end devices, then you might prefer a more<br>
integrated design like XSalsa20. But then you have to customize it<br>
for every cipher.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Alternatively, we've thought about generalizing Noise Pipes to support<br>
PSK-based resumption, which can give similar performance, so that<br>
might be a better option for cases that need extreme speed.<br></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra">Brian</div>-- <br><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://briansmith.org/" target="_blank">https://briansmith.org/</a></div></div></div></div></div></div></div>
</div></div>