[Cryptography] Unique nonce vs new key

[Christian Huitema]

On 3/9/2021 1:11 PM, Phillip Hallam-Baker wrote:
> 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.
>
> 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.

You may want to be very clear about the vocabulary, in particular the 
use of the word "session".

>
> 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.

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.

>
> In theory, the 'same key, fresh nonce' approach means the key schedule 
> can be reused. But does this really buy me very much?

I can't tell for your application. For QUIC, computing the key schedule 
once for a million packets is certainly a good thing.

> 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.
>
> 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.
>
> 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.
>
>
> Thoughts? Comments?

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.

-- Christian Huitema

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210309/895d8004/attachment.htm>