Re: Packet Number Encryption outside of AEAD

Kazuho Oku <> Sat, 28 July 2018 13:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 091D6130EA3 for <>; Sat, 28 Jul 2018 06:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 firorite0JWe for <>; Sat, 28 Jul 2018 06:16:05 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F38B1130E8C for <>; Sat, 28 Jul 2018 06:16:04 -0700 (PDT)
Received: by with SMTP id r13-v6so6723915ljg.10 for <>; Sat, 28 Jul 2018 06:16:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=2ZTLiP1tGVL6iD72wpZ5OYMQ6I7R7BSmrhsD6/Yuo44=; b=OO+wzydVQUU5KDm0Uubh6eDJIaVs/dFtEgUexYnZBkrFRpQgcKgOZZgmqJj+Y0S/7h kC3/PAiOHZn/MJiEBsEZbN+VNtDyKGmukecOeuqp8bH76ri6K3/uk8c8+qB1NVDLTjuM 5Ty3jJoXVkWLUZWQOYuHmiKO5m+SMmHjhPONmrOpsFYyCZqCZjLXBmOWdG2XeDpOuGSw 6CeRabBYYIVLu6U7zxWeRcxy/1E2KrDTTIcNEQMjNCqojFx9rxNM837l3zrZXC8ah1F3 wEeDFUHY8AQzaOx4Id55tecGc3PFUd7GEzKRMgui3P5QC/BXqNBtzsmY7V8TEHMOdBna 8osw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=2ZTLiP1tGVL6iD72wpZ5OYMQ6I7R7BSmrhsD6/Yuo44=; b=FQ78oisrirqbinX09IqRP9g5SlEyOhMQ0zXVbUKkYqTrg34ogsGB7GEnO2DyrXxiK2 qZCAjSxsoS4sxyiFSsfB/t+MHQ306EFtiDiXu2no3h23vUJ+Ub0ZjukHD8CvCXCsOHBg c4tznTQLLhFFiTgLLbkjZlfO5YCU9FtEPe/iM28PqZV+AsgIdM4SkgLggX7oZZ6i/z9N +sMt7WnnGKm5TqsOcmRZMhsAhiY2swHRiFSOqsVmaS3Xgb+1yZAM5cgYnsbo/fDQ1a6l xIJHw7srV4dQLERMqe0s04ju+7gHq5iAQxqtRwCp75Cr9hY04tjv/8sh5ccGl6Anww33 P7UA==
X-Gm-Message-State: AOUpUlGf+igsAPlY5OiomCjUR5JHn3bdCgPbdSl9M+YTIkYDHYHfgFge 0Az4MEdKWzpnpcpDCW10mVCkfpRW3lCWmQHOD48=
X-Google-Smtp-Source: AAOMgpftZzG3vQ9hOEn2bnSQXH1BpTfCtnvEre5DxzN6eAbZKVk05KfSaY6/XA+PtbAl32aM8yLWiFOFlbRzW6eWU60=
X-Received: by 2002:a2e:8147:: with SMTP id t7-v6mr8314909ljg.32.1532783763277; Sat, 28 Jul 2018 06:16:03 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 06:16:02 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <>
From: Kazuho Oku <>
Date: Sat, 28 Jul 2018 22:16:02 +0900
Message-ID: <>
Subject: Re: Packet Number Encryption outside of AEAD
To: "Deval, Manasi" <>
Cc: Christian Huitema <>, =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <>, IETF QUIC WG <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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:16:07 -0000

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