RE: aes128gcm: why verify padding?

"Manger, James" <> Mon, 23 January 2017 12:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6215D1295F1 for <>; Mon, 23 Jan 2017 04:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.1
X-Spam-Status: No, score=-10.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IrCTSuIh9sSo for <>; Mon, 23 Jan 2017 04:51:59 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D38CA1295F6 for <>; Mon, 23 Jan 2017 04:51:59 -0800 (PST)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1cVe2t-0004lb-1k for; Mon, 23 Jan 2017 12:48:27 +0000
Resent-Date: Mon, 23 Jan 2017 12:48:27 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1cVe2n-0004k2-9x for; Mon, 23 Jan 2017 12:48:21 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <>) id 1cVe2f-0003jp-76 for; Mon, 23 Jan 2017 12:48:15 +0000
X-IronPort-AV: E=Sophos;i="5.33,274,1477918800"; d="scan'208";a="20431846"
Received: from unknown (HELO ([]) by with ESMTP; 23 Jan 2017 23:47:39 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8416"; a="383415015"
Received: from ([]) by with ESMTP; 23 Jan 2017 23:47:39 +1100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 23 Jan 2017 23:47:39 +1100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 23 Jan 2017 23:47:38 +1100
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Mon, 23 Jan 2017 23:47:38 +1100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dOFe1r7Yp+R5AOvR2WkK5Ml5GW7jtNN/f9Lok/njWzI=; b=B/SLy4NzG0/5/P9aunl1N28y4uOd+nFT07HVL7lTuT2c6taNx3WsdDPfDxhArPGbu/McQFoIxP73TUw8O/wMbVmuog/23dr8PJ4EeNzdPFkKdWN9l36rLpEQZ/eURsgZHFbxlnyMTIhVc07zw/J4Gy6BJ3v1tqKcGZ7zc/zV2/c=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 23 Jan 2017 12:47:37 +0000
Received: from ([]) by ([]) with mapi id 15.01.0860.021; Mon, 23 Jan 2017 12:47:37 +0000
From: "Manger, James" <>
To: "" <>
CC: Martin Thomson <>, "" <>
Thread-Topic: aes128gcm: why verify padding?
Thread-Index: AdJvg9D1nChV1RXVTGiVAO+6sRrzlwADDv6AAAAcAeAADb7rAAFW7FVwAAoO2IAACMzpgA==
Date: Mon, 23 Jan 2017 12:47:37 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-AU, en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-originating-ip: []
x-ms-office365-filtering-correlation-id: 4eab2371-22e6-4c3e-5f35-08d4438e028f
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1616;
x-microsoft-exchange-diagnostics: 1; SYXPR01MB1616; 7:GVWcM4WdtYn+L3aeq/FQ1cQwx2/Ph5c3yQWVp4rqo9+KOI1syv0YWUrD9Nupq/fzEecjczqCrLs3LucIT3fLAPchOgwlU0i1Zp7XbFzkSwRaFVz4D08VGuKv+6z2YzdX0wQzLQYBs2rsOGLDf5ZYAKw95GUUA7F/UIZUDbx30T/XlM0OckIKb/LRtbIiRFDZjAayysKCYf+Pc5MYGZddMOU5ftzOsKPRRDqyMmY0t4UZnpZKW1YCFyEHQtQ11R3Wz8JMNuZdn4sSvExtoSo89nJcekxtxN9Aq7a2QzWVwAQvMeNgfnL2lPx+XtlY1+wrUni4TD3d24q94aKZQZr5v15QwTNzJIbNjNqq+zMji1LdPySvr3BENxnloDGhkxyyPQqH5ohOm/+ibeDqFDqbOuHMigqF3vd2xxwRvwbJZFsXSJu8EOcRGw0PECYsZZn2E4qvcndwbz3I38ikABjcnQ==
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(166708455590820)(272811157607776)(67441168502697);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123564025)(6072148)(6042181); SRVR:SYXPR01MB1616; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1616;
x-forefront-prvs: 0196A226D1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(13464003)(24454002)(377454003)(74316002)(305945005)(86362001)(105586002)(7736002)(189998001)(54906002)(25786008)(229853002)(77096006)(39060400001)(97736004)(38730400001)(55016002)(6506006)(6436002)(5640700003)(110136003)(99286003)(6306002)(9686003)(66066001)(2501003)(3280700002)(3846002)(6116002)(2950100002)(2351001)(4326007)(102836003)(42882006)(6916009)(106356001)(7696004)(92566002)(1730700003)(8676002)(33656002)(5660300001)(81156014)(15650500001)(2906002)(81166006)(101416001)(2900100001)(53936002)(68736007)(76176999)(3660700001)(93886004)(122556002)(54356999)(8936002)(50986999); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1616;; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2017 12:47:37.1868 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1616
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-2.1
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, W3C_NW=0.5
X-W3C-Scan-Sig: 1cVe2f-0003jp-76 a3735bcfb3c3bb48029837cfb44796c1
Subject: RE: aes128gcm: why verify padding?
Archived-At: <>
X-Mailing-List: <> archive/latest/33357
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

A padding byte to distinguish intermediate and final records could indeed work.

It doesn't consume any extra bytes in this scheme as it piggy-backs on an end-of-padding byte. But in a different multiple-AEAD-record scheme that didn't offer padding (a nice, but not strictly necessary feature) it wouldn't be so ideal. I've seen ideas to put the first-vs-intermediate-vs-last indicator in the nonce, in the KDF, in the AAD, in the record length, and now in the plaintext. I'm not sure how to pick.

What do you do if last non-zero byte isn't 0x01 or 0x02?

> And while we are at breaking things, it would be good time to make
rs count ciphertext, not plaintext, right?

That's already in the editor's draft (

James Manger

-----Original Message-----
From: [] 
Sent: Monday, 23 January 2017 6:36 PM
To: Manger, James <>
Cc: Martin Thomson <>;
Subject: Re: aes128gcm: why verify padding?

On Mon, Jan 23, 2017 at 04:28:55AM +0000, Manger, James wrote:
> After implementing aes128gcm I have another reason to adjust the
> padding scheme. Putting the content first, before the padding
> (whatever format), will save moving the content after decryption
> in some (typical?) implementations. A Decrypt API will typically
> expect the content to be at the start of a given buffer. For
> instance, my implementation decrypts to a given buffer, but due
> to the current padding scheme (<padlen><padding><content>) then
> needs to copy the data to the start of the buffer (shifting it 2
> bytes backwards in typical no-padding situations). If, instead,
> the content came first then the data wouldn't need to be moved.
> So I would support a padding scheme similar to TLS 1.3:
> <content><non-zero byte><zeros…>.

Furthermore, if the nonzero byte was 0x01 for non-final blocks and
0x81 for final block (or any two different nonzero values), then
that would also solve the truncation flaw from last message, no?

And while we are at breaking things, it would be good time to make
rs count ciphertext, not plaintext, right?