Re: Packet Number Encryption outside of AEAD

Mikkel Fahnøe Jørgensen <> Sat, 28 July 2018 13:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A784130EB7 for <>; Sat, 28 Jul 2018 06:44:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H-C4zfts62_s for <>; Sat, 28 Jul 2018 06:44:37 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c0b::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CFFF130DD4 for <>; Sat, 28 Jul 2018 06:44:37 -0700 (PDT)
Received: by with SMTP id g191-v6so414324ita.0 for <>; Sat, 28 Jul 2018 06:44:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=oOZmS30BwzRb4/sie7tkGMBFEB/s+T2V83tveyOn70s=; b=avcNo9RQEnZ3akg3NJHlZp/iJUzY6qZYtZVl0e5/HQhDoD85eljxFU6jnFplzAINGC IrSEVjZcqXgHiD5zjL3FLm9IS9IQAFI9wNI6B2AnB41ZqPaK62Lk/jTHUz/2m23LE29E YFgjBgNtmgXIDTRb5fRd1t7YTMkAYr5rJ4VnexF6z4B4pxnkG+vcf0T2HwYqi5pr5w17 A60rxpcR5MqPedaUT8+FGfVM6SrF6IApa0Ru6ll2Jk2+Io7VS/XTo3rZb5lzps+x6e2j 9+4sUqv5aPgxJqBUnC/5fsnH7hipk7r7yb/A+xr60v7oZimL/OjzYuZ1h7N0fKHPUDRI VtwQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=oOZmS30BwzRb4/sie7tkGMBFEB/s+T2V83tveyOn70s=; b=bGzFyjQTD9RoipR76lblSQYCtfXB0Z+9LT5n+MncNy50JXdwQNtFJoaiXY4R48gj6/ oqreQyFcrXD+7MTZ++492vX/VTuSlhmZW01uORO5shXtg+gPRk8oCUh/mk0xNgwKklZi 2NB22hrk23krUkXaHhkIWPx8rZgE+TGDGhtDDJtg0abLFPSQhNStPkxVtiD8+w4jkNh5 SGHR6dRc8KqqGNjUegxPHRQ7XwTqW1n7mV665IcUl8JnVyyzqv77cSJK5+E2d7wCS84q ZQw2DpZoZ2qoKvomyNE7rVzY2Fk43uKxJyNiaEueP+tR3LYp0hbCOtqulqEX8/wrGye+ Nk9A==
X-Gm-Message-State: AOUpUlGWIYOQuJL163kFlu/4zQX1g4DdJZ+BboKVNggb5pv0C4JwZibW 3FeJ4327B9O5VfT4W6/GaidJqM9tng2XUWHLnQO/ZA==
X-Google-Smtp-Source: AAOMgpfAwd4H6vfqng02c8C8hI7ga56pzOhu7vFET0KTq/h6dB19SFFTFmPAqJzJCWbu6VTN6i69DBt1n89N7pVq8QA=
X-Received: by 2002:a02:8c3c:: with SMTP id l57-v6mr10050203jak.57.1532785476367; Sat, 28 Jul 2018 06:44:36 -0700 (PDT)
Received: from 1058052472880 named unknown by with HTTPREST; Sat, 28 Jul 2018 06:44:35 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>
In-Reply-To: <>
References: <> <> <> <> <>
X-Mailer: Airmail (420)
MIME-Version: 1.0
Date: Sat, 28 Jul 2018 06:44:35 -0700
Message-ID: <>
Subject: Re: Packet Number Encryption outside of AEAD
To: "Deval, Manasi" <>, Kazuho Oku <>
Cc: Christian Huitema <>, IETF QUIC WG <>
Content-Type: multipart/alternative; boundary="000000000000d60a3805720f6dbb"
Archived-At: <>
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Jul 2018 13:44:40 -0000

You can have one core with access to an input queue that does nothing but
decrypting packet numbers.
The decrypted PN’s are placed on a queue.
Meanwhile one or several other cores verify the AEAD tag and places
validation on a queue.
A third set of cores processes decryption and places decrypted packets on a
queue. High priority frames are read from the decrypted packet queue and
processed, pending tag confirmation.
A fourth set of cores deal with ACK processing and other packet number
sensitive content.

If the original receive buffer needs to be modified, you first incur the
PNE decryption delay, then you force a possibly shared cache line into
exclusive mode by writing to the buffer. The separate concurrent stages now
not only have to wait for PNE, but also for the inter-processor cache
coherency synchronisation to take effect.

For encoding there are fewer benefits, but one is that you can encrypt
buffers without deciding the packet number immediately. This might be
helpful if sending via multiple cores feeding to a final transmit process
that synchronises packet numbers and applies PNE before sending data on the

Kind Regards,
Mikkel Fahnøe Jørgensen

On 28 July 2018 at 15.16.03, Kazuho Oku ( wrote:

2018-07-28 7:11 GMT+09:00 Deval, Manasi <>:
> About the issue of Packet Number Encryption outside of AEAD - We agree it
simplifies both hardware and software logic. It also allows the2 encryption
operations to run mostly in parallel, so it is a welcome modification.

Would you mind elaborating a bit on how the proposed change would help

My understanding is that it does not help parallelizing "encryption",
because the only change is if you have the cleartext PN (which is
something you can prepare beforehand) as part of the AAD.

I also do not understand how it helps parallelizing decryption in practice.

The proposed change removes cleartext PN from AAD. It sounds like that
you would then have a chance to start processing AAD for GCM. But I am
not sure if that is correct.

In the current approach, input to GCM is: GCM(first-octet || CID ||
plaintext-PN || payload).

With the proposed change, it becomes: GCM(fist-octet || CID || payload).

Because where the payload begins depends on the value of the PN being
decrypted, in both cases you have the same degree of parallelism. You
can process GCM to the end of CID, but no more.

To conclude, I do not see how the proposed change helps parallelize
the encoder or the decoder.

> Thanks,
> Manasi
> -----Original Message-----
> From: QUIC [] On Behalf Of Christian Huitema
> Sent: Friday, July 27, 2018 6:43 AM
> To: Kazuho Oku <>; Mikkel Fahnøe Jørgensen <>
> Subject: Re: Packet Number Encryption outside of AEAD
> On 7/26/2018 9:14 PM, Kazuho Oku wrote:
>> Consider the case where a sender encodes a packet number using 4
>> octets even when just using 1 octet is enough.
>> An on-path attacker rewrites the packet by applying XOR 0x80 to the
>> first octet of the encrypted PN, and trimming the latter three octets
>> of the encrypted PN.
> That attack does not work, because the encoding of the PN is big-endian.
> The actual packet number is in the fourth octet. Or rather, it only
> works in the special case where the PN is 0.
> -- Christian Huitema

Kazuho Oku