[prev in list] [next in list] [prev in thread] [next in thread] 

List:       moderncrypto-noise
Subject:    Re: [noise] encrypted nonce / udp packet number
From:       Trevor Perrin <trevp () trevp ! net>
Date:       2018-07-21 17:53:48
Message-ID: CAGZ8ZG3Oa_UwRHRX6vC7YyU4RLxWqh-S5PtKKPDx2mbuZ+3gnw () mail ! gmail ! com
[Download RAW message or body]

On Sat, Jul 21, 2018 at 12:51 AM, Rhys Weatherley
<rhys.weatherley@gmail.com> wrote:
> On Sat, Jul 21, 2018 at 9:11 AM, Arvid Picciani <aep@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?


Hi Arvid,

It's a good question.  I think Rhy's description is correct:


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


As Rhys says, they are deriving separate keys for message encryption
and packet-number encryption.

https://tools.ietf.org/html/draft-ietf-quic-tls-13

The message encryption is done first, using the packet number as the nonce.

Then some of the ciphertext from this first encryption is used as a
nonce for the packet number encryption.  They also just use
counter-mode encryption for the packet number, without an
authentication tag.  Presumably the theory is that a bad packet number
will just cause a failure to decrypt the message.

Noise already has the requirement that ciphertext be indistinguishable
from random if the key is random, so could be used for this.  In Noise
terms, you could derive a packet-number encryption key with the ASK
mechanism (still being discussed).

Trevor
_______________________________________________
Noise mailing list
Noise@moderncrypto.org
https://moderncrypto.org/mailman/listinfo/noise

[prev in list] [next in list] [prev in thread] [next in thread]