<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 2/14/2021 7:43 PM, jrzx wrote:<br>
</div>
<blockquote type="cite"
cite="mid:SV9pxsjIuJf9W5tbcBkDKakFKPJwxb0r4I4-avU7S0IoPNe-AH_mDISo-EbJ1NEC2iW6AIJ2a_Un2XC6F5qrfFoA5rOKySGuYXn0H6fbCHk=@protonmail.ch">
<div class="moz-text-plain" wrap="true" graphical-quote="true"
style="font-family: -moz-fixed; font-size: 13px;"
lang="x-unicode">
<pre class="moz-quote-pre" wrap="">On Sunday, February 14, 2021 5:10 PM, Christian Huitema <a class="moz-txt-link-rfc2396E" href="mailto:huitema@huitema.net" moz-do-not-send="true"><huitema@huitema.net></a> wrote:
</pre>
<blockquote type="cite" style="color: #007cff;">
<pre class="moz-quote-pre" wrap="">I see AES-GSM (and ChaCha20-Poly1035) as the
two options used to secure QUIC packets. The common knowledge
is that.
this is fine as long as a three conditions hold: a different
Nonce is used for each packet, which in QUIC is done by
XORing a secret-dependent IV with the 64 bit packet
sequence number;
the amount of data encrypted
with the same key is limited, which in QUIC is done by
forcing a key rotation after 2<sup class="moz-txt-sup"><span style="display:inline-block;width:0;height:0;overflow:hidden">^</span>26</sup> packets for AES-GCM;
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">Why?
Please explain
ChaCha20 is equivalent to a well known to everyone or easily calculated stream of random bits 2<sup class="moz-txt-sup"><span style="display:inline-block;width:0;height:0;overflow:hidden">^</span>393</sup> bits or so long, after which it repeats.
The shared secret is the position in this stream, the common practice being that the high order 256 bits are the shared secret, the middle sixty four bits are the nonce, and the last sixty four bits of the position are your packet's position.
So you should not need to change your nonce until you are approaching 2<sup class="moz-txt-sup"><span style="display:inline-block;width:0;height:0;overflow:hidden">^</span>64</sup> bytes of data.
XChaCha20 has the nonce overlap with the packet position, and if the packet position overflows, increments the nonce, which is effectively equivalent no nonce, and instead a random starting position for each group of packets is effectively the nonce, all the starting positions having the same shared secret starting 256 high order bits, and different (but non secret) low order positions.
Where is the security vulnerability?
It is too easy to glibly claim security vulnerabilities, as we just saw with people claiming that Bitcoin's signatures were vulnerable to pollard rho.
Such glib claims lead to pointless superstitions resulting in unnecessary and error prone complexity.</pre>
</div>
</blockquote>
<p>I wrote "forcing a key rotation after 2<sup class="moz-txt-sup"><span
style="display:inline-block;width:0;height:0;overflow:hidden">^</span>26</sup>
packets for AES-GCM". Did not mention ChaCha20-Poly1035. Per
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-ietf-quic-tls/">https://datatracker.ietf.org/doc/draft-ietf-quic-tls/</a>, this is
only a requirement for AES-GCM, not ChaCha20-Poly1035. The draft
says "For AEAD_CHACHA20_POLY1305, the confidentiality limit is
greater than the number of possible packets (2^62) and so can be
disregarded."</p>
<p>-- Christian Huitema
</p>
</body>
</html>