<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 21, 2018 at 9:11 AM, Arvid Picciani <span dir="ltr"><<a href="mailto:aep@exys.org" target="_blank">aep@exys.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">the QUIC protocol apparantly is able to encrypt the packet sequence<br>
number (separately from the payload)<br>
<br>
<a href="https://tools.ietf.org/html/draft-ietf-quic-tls-13#section-5.3" rel="noreferrer" target="_blank">https://tools.ietf.org/html/<wbr>draft-ietf-quic-tls-13#<wbr>section-5.3</a><br>
<br>
does anyone understand how they do this at all?<br>
As far as i understand, it is not safe to reuse the same nonce for an<br>
AEAD with different plaintext,<br>
so without having a unique nonce, how do you encrypt the .. nonce?<br></blockquote><div><br></div></div><div class="gmail_quote">From section 5.3.1 of the draft (AES mode), they are doing this:</div><div class="gmail_quote"><br></div><div class="gmail_quote">    encrypted_pn = AES-CTR(pn_key, sample, packet_number)<br></div></div><div class="gmail_extra"><br></div><div class="gmail_extra">The "sample" is used as the CTR value and is made up of 16 bytes, sampled from a subset of the encrypted packet's ciphertext beyond the header portion.  Presumably this value will be different for every packet as long as the cipher is a strong pseudorandom function (PRF).<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The "pn_key" is derived from the session's shared secrets separately from the regular packet encryption key to provide domain separation.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">The ChaCha20 version is similar - the packet's ciphertext is used as the nonce with a separate key to encrypt the packet number.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't know enough about QUIC to know if this really helps.  If QUIC packet numbers are generated in increasing order from the start of the session, then guessing what they are under the encryption layer plus or minus some delta shouldn't be hard.  Is the packet number encryption actually helping?  Dunno.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Aside: Separately I've thought about using Noise with datagram transports while keeping overhead low.  One of my ideas was to use an 8-bit packet number with the high 56-bits of the starting nonce generated from ck somehow (as an ASK?).  The session uses a sliding window of valid packet numbers to gradually move the high bits forward as the window wraps around.  The starting nonce would be unpredictable, with only the low 8 bits of the packet number known publicly.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra"></div><div class="gmail_extra">Cheers,</div><div class="gmail_extra"><br></div><div class="gmail_extra">Rhys.<br></div></div>