[noise] encrypted nonce / udp packet number

[Rhys Weatherley]

On Sat, Jul 21, 2018 at 9:11 AM, Arvid Picciani <aep at exys.org> wrote:

> the QUIC protocol apparantly is able to encrypt the packet sequence
> number (separately from the payload)
>
> https://tools.ietf.org/html/draft-ietf-quic-tls-13#section-5.3
>
> does anyone understand how they do this at all?
> As far as i understand, it is not safe to reuse the same nonce for an
> AEAD with different plaintext,
> so without having a unique nonce, how do you encrypt the .. nonce?
>

>From section 5.3.1 of the draft (AES mode), they are doing this:

    encrypted_pn = AES-CTR(pn_key, sample, packet_number)

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

The "pn_key" is derived from the session's shared secrets separately from
the regular packet encryption key to provide domain separation.

The ChaCha20 version is similar - the packet's ciphertext is used as the
nonce with a separate key to encrypt the packet number.

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.

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.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20180721/aad67496/attachment.html>