<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 22, 2021 at 1:02 AM Christian Huitema <<a href="mailto:huitema@huitema.net">huitema@huitema.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
On 7/20/2021 6:48 PM, Ray Dillinger wrote:<br>
><br>
> On 7/20/21 6:11 PM, Peter Gutmann wrote:<br>
>> Ray Dillinger <<a href="mailto:bear@sonic.net" target="_blank">bear@sonic.net</a>> writes:<br>
>><br>
>>> I don't think NaCl as it is today is vulnerable<br>
>> Unless it's changed recently, the NaCL API assumes the nonce is user-supplied,<br>
>> which means it's completely vulnerable.  It's RC4 as used in the 1990s all<br>
>> over again.<br>
>><br>
>> Peter.<br>
><br>
> Aw crap.  I'm so sorry to hear that, I thought it was better.<br>
<br>
For AEAD, both ends of a communication channel have to agree on what the <br>
nonce is, and communication protocols have to specify that. For example, <br>
the nonce used in QUIC is a 64 bit packet number, guaranteed to occur at <br>
most once for the duration of the connection. But only the least <br>
significant bits of the packet number are sent in the packet, the rest <br>
is inferred. Which means the nonce is only known by the protocol logic. <br>
There has to be an API to pass it to the implementation of AES-GCM or <br>
ChaCha-poly. Which means the crypto library API needs to assume that the <br>
nonce is user supplied.<br>
<br>
-- Christian Huitema<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">I would consider the application choosing the nonce for me to be an anti-pattern because it creates a side channel that allows the crypto implementation to leak information.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I don't trust any implementation 100% and random number generators are particularly suspect. So as a general rule I consider the raw output of a random number generator to be sensitive and never reveal it to any other party without processing it through a one way function.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My preferred construction is to use an HMAC under a secret key to post-process the RNG output. </div><div class="gmail_default" style="font-size:small"></div></div></div>