<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 3/9/2021 1:11 PM, Phillip
Hallam-Baker wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAMm+LwgGOEs6LiKV5D9p-GyQ6RdMiihf9AbZy=9Q1YyZEqW2Dg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">I am
looking at the details of my packetizer and have come across
the following design choice that I would like to understand
a bit better.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">QUIC, SSL
and everything else adopt the approach of negotiating an AES
key and then creating a fresh iv/nonce per AES session which
might be a single packet or a group of packets, lets call
that a chunk for now. The distinguishing feature of a chunk
is it has a fresh nonce at the start and results in
computing a fresh authentication tag.</div>
</div>
</div>
</blockquote>
<p>You may want to be very clear about the vocabulary, in particular
the use of the word "session".</p>
<blockquote type="cite"
cite="mid:CAMm+LwgGOEs6LiKV5D9p-GyQ6RdMiihf9AbZy=9Q1YyZEqW2Dg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">I am
thinking of a different approach, I generate a primary key
and then specify a nonce to some form of KDF function from
which I derive the AES iv/nonce and key. This means I am
performing a KDF per chunk and an AES key setup per chunk.</div>
</div>
</div>
</blockquote>
<p>That's pretty much what QUIC does, "specify a [master secret] to
some form of KDF function from which I derive the AES iv and key".
Then, for each packet, the iv is xor-ed with the unique sequence
number of the packet to generate the nonce used for encrypting
that packet.<br>
</p>
<blockquote type="cite"
cite="mid:CAMm+LwgGOEs6LiKV5D9p-GyQ6RdMiihf9AbZy=9Q1YyZEqW2Dg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">In theory,
the 'same key, fresh nonce' approach means the key schedule
can be reused. But does this really buy me very much?</div>
</div>
</div>
</blockquote>
<p>I can't tell for your application. For QUIC, computing the key
schedule once for a million packets is certainly a good thing.<br>
</p>
<blockquote type="cite"
cite="mid:CAMm+LwgGOEs6LiKV5D9p-GyQ6RdMiihf9AbZy=9Q1YyZEqW2Dg@mail.gmail.com">
<div dir="ltr">
<div dir="ltr">
<div class="gmail_default" style="font-size:small">There are
two use scenarios I am considering, one is 'each packet is a
fresh chunk'. The other is 'groups of related packets go in
the same chunk.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">The idea
here being that in a streaming video context or the like,
there are collections of data within the stream that are all
or nothing. Either I have a full frame of video data I can
process or I aborted part way through because it was stale
and will simply chuck it away. </div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">I doubt
that I would ever want a chunk to be more than a few hundred
KB simply because even if I am dealing with tens of TB of
data, I want to have integrity checking at a much more
granular level. My AES authentication tag is not just my
protection against malice, it is my extended checksum as
well.</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small"><br>
</div>
<div class="gmail_default" style="font-size:small">Thoughts?
Comments?</div>
</div>
</div>
</blockquote>
<p>It does depend on your application of course. But as far as
streaming a video over multiple packets, you have to consider what
happens if some packets need to be repeated, or if you find out
midway through that the packet size supported by the path has
changed. Then you have to consider robustness to traffic
fingerprinting, etc. In the end, it tends to be either something
like QUIC, in which each packet has its own nonce and checksum, or
something like encrypting the whole video stream and then sending
that over something like TCP.</p>
<p>-- Christian Huitema<br>
</p>
</body>
</html>