RE: aes128gcm: why verify padding?
"Manger, James" <James.H.Manger@team.telstra.com> Mon, 30 January 2017 05:26 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC4BA129413 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 29 Jan 2017 21:26:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.119
X-Spam-Level:
X-Spam-Status: No, score=-10.119 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=teamtelstra.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCDgnlP0kGZM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 29 Jan 2017 21:26:53 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D324129408 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 29 Jan 2017 21:26:53 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cY4RV-0001pY-OZ for ietf-http-wg-dist@listhub.w3.org; Mon, 30 Jan 2017 05:23:53 +0000
Resent-Date: Mon, 30 Jan 2017 05:23:53 +0000
Resent-Message-Id: <E1cY4RV-0001pY-OZ@frink.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by frink.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <James.H.Manger@team.telstra.com>) id 1cY4RO-0001oK-Lq for ietf-http-wg@listhub.w3.org; Mon, 30 Jan 2017 05:23:46 +0000
Received: from ipxbvo.tcif.telstra.com.au ([203.35.135.204]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <James.H.Manger@team.telstra.com>) id 1cY4RH-00041k-54 for ietf-http-wg@w3.org; Mon, 30 Jan 2017 05:23:41 +0000
X-IronPort-AV: E=Sophos;i="5.33,310,1477918800"; d="scan'208";a="135380756"
Received: from unknown (HELO ipcavi.tcif.telstra.com.au) ([10.97.217.200]) by ipobvi.tcif.telstra.com.au with ESMTP; 30 Jan 2017 16:23:06 +1100
X-IronPort-AV: E=McAfee;i="5700,7163,8423"; a="387300702"
Received: from wsmsg3706.srv.dir.telstra.com ([172.49.40.80]) by ipcavi.tcif.telstra.com.au with ESMTP; 30 Jan 2017 16:23:05 +1100
Received: from wsapp5871.srv.dir.telstra.com (10.75.139.13) by wsmsg3706.srv.dir.telstra.com (172.49.40.80) with Microsoft SMTP Server (TLS) id 8.3.485.1; Mon, 30 Jan 2017 16:23:05 +1100
Received: from wsapp5585.srv.dir.telstra.com (10.75.3.67) by wsapp5871.srv.dir.telstra.com (10.75.139.13) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 30 Jan 2017 16:23:05 +1100
Received: from AUS01-SY3-obe.outbound.protection.outlook.com (10.172.229.125) by wsapp5585.srv.dir.telstra.com (10.75.3.67) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Mon, 30 Jan 2017 16:23:05 +1100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=teamtelstra.onmicrosoft.com; s=selector1-team-telstra-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Ivm8o/tKTtbKHzBJ+hz2D9c892VAL52WSflEDDW/PXw=; b=ForLcbcmdQuGNq65J7sBlqAYmJTJfgyHEn4mLg0j2pGz5Bx1Djxr9ciLN21jZ8TVr+pGC8o2AaHDQqSRcBDn1pPY4W6g0Yw+XBSAxjnNky/me8gdd/WhHvhwi2b6UsJelhKiKWBvo/s1iVxIK5nXrSsHZ5k2rleLIZlMgeA5FZ8=
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) by SYXPR01MB1615.ausprd01.prod.outlook.com (10.175.209.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.13; Mon, 30 Jan 2017 05:23:03 +0000
Received: from SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) by SYXPR01MB1615.ausprd01.prod.outlook.com ([10.175.209.15]) with mapi id 15.01.0860.024; Mon, 30 Jan 2017 05:23:03 +0000
From: "Manger, James" <James.H.Manger@team.telstra.com>
To: Martin Thomson <martin.thomson@gmail.com>
CC: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Thread-Topic: aes128gcm: why verify padding?
Thread-Index: AdJvg9D1nChV1RXVTGiVAO+6sRrzlwADDv6AAAAcAeAADb7rAAFW7FVwAAoO2IAACMzpgAAYx0WAAAAn4DAAZJKWgAAzIAMQAA8vZIAAi3LTUAADA3iAAAC57JA=
Date: Mon, 30 Jan 2017 05:23:03 +0000
Message-ID: <SYXPR01MB16153632AEC9FCA5889C9EB1E54B0@SYXPR01MB1615.ausprd01.prod.outlook.com>
References: <CABkgnnUo-tf69AzJC=OUy2rjDZwedTd5Ua9mhOiJBqaA0VKrYw@mail.gmail.com> <SYXPR01MB16150F4D3D19CC69D18E1A09E57D0@SYXPR01MB1615.ausprd01.prod.outlook.com> <CABkgnnV_OatRWyZBE3Rak22gS1jrOZKjCGwOePpbqJCAeJFM4Q@mail.gmail.com> <SYXPR01MB1615DD56268D7EF9929F3DBFE5720@SYXPR01MB1615.ausprd01.prod.outlook.com> <20170123073623.GA28101@LK-Perkele-V2.elisa-laajakaista.fi> <SYXPR01MB1615798CC057FB3232B2FA4BE5720@SYXPR01MB1615.ausprd01.prod.outlook.com> <CABkgnnW4e+FOz+gsu6vZ2d9WOSv9Yohn+OejrNom9HCBiMrRWQ@mail.gmail.com> <SYXPR01MB1615AE56D810A0372AF811FCE5750@SYXPR01MB1615.ausprd01.prod.outlook.com> <CABkgnnWoSWCeV_TUwDY1J00ivY0TDgU_9NhiSWZpM4_F6XAYfA@mail.gmail.com> <SYXPR01MB1615C769ADDAF813BB32A65DE5760@SYXPR01MB1615.ausprd01.prod.outlook.com> <20170127072041.GA16072@LK-Perkele-V2.elisa-laajakaista.fi> <SYXPR01MB16157AC6FFBC54BA8A046AF6E54B0@SYXPR01MB1615.ausprd01.prod.outlook.com> <CABkgnnXYc3V3FoVH_TsBUMZes5r3uZaTLs4zdFPXNMg178ppFw@mail.gmail.com>
In-Reply-To: <CABkgnnXYc3V3FoVH_TsBUMZes5r3uZaTLs4zdFPXNMg178ppFw@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=James.H.Manger@team.telstra.com;
x-originating-ip: [203.41.142.244]
x-ms-office365-filtering-correlation-id: 0b927ede-2c23-47dd-31d1-08d448d01096
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:SYXPR01MB1615;
x-microsoft-exchange-diagnostics: 1; SYXPR01MB1615; 7:GR/aTBDxW/5VXMHeGjmbKkvSoQQ1z/walvZneGIyKCcs3jO7+UkUOhxixLzjUxKb/kqYJiFtl6cEd0PIGZKCwrEJsb0Vg575jwvbN1PXPB4Llpxdc0yg9FoDsJESaRUt/iuCoaG2YgVCvOfUUrBDN6pqQckd9GK2x6EsZ7Ame6CN+k83HyAFwWCpuYQ3PfCmIPwPtbZAaLCZ314kXMlVPx0o75EJgpiy+w6j8d0jxxWhmMBTTCSrO5lbaeOtLKEdT6JiQC2C2I6T79PiZ4BSlq9InJvpEomXE/Tp4YbScYkAcJ8F/g7njJi1LcIK71rtDv6w/Sovc9JtpgYYAC1xwoaBf8UTTGh+JmoW4cHJ4ealIyVanZLUnInTe7HLTwN8s0JU4GWKHRlxsiaN60m6ZeKke96EqANyhkjolN+1QlGhpEsLJJtVg9w3CxBRcFIETpi39hpS+bdL+WHwefR8KQ==
x-microsoft-antispam-prvs: <SYXPR01MB161514A10B95A0FA6FBEF79EE54B0@SYXPR01MB1615.ausprd01.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(272811157607776)(67441168502697);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:SYXPR01MB1615; BCL:0; PCL:0; RULEID:; SRVR:SYXPR01MB1615;
x-forefront-prvs: 0203C93D51
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(199003)(13464003)(24454002)(377454003)(51444003)(189002)(74316002)(50986999)(305945005)(7736002)(10000500002)(5660300001)(3846002)(189998001)(102836003)(6116002)(97736004)(68736007)(81156014)(76176999)(2950100002)(42882006)(6916009)(8676002)(54356999)(53936002)(81166006)(8936002)(38730400001)(92566002)(2900100001)(6506006)(54906002)(2906002)(55016002)(99286003)(229853002)(39060400001)(4326007)(7696004)(122556002)(77096006)(33656002)(3280700002)(3660700001)(66066001)(86362001)(25786008)(110136003)(101416001)(106356001)(6436002)(105586002)(93886004)(10750500005)(9686003)(15650500001); DIR:OUT; SFP:1102; SCL:1; SRVR:SYXPR01MB1615; H:SYXPR01MB1615.ausprd01.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en;
received-spf: None (protection.outlook.com: team.telstra.com 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: 30 Jan 2017 05:23:03.3447 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 49dfc6a3-5fb7-49f4-adea-c54e725bb854
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SYXPR01MB1615
X-OriginatorOrg: team.telstra.com
Received-SPF: none client-ip=203.35.135.204; envelope-from=James.H.Manger@team.telstra.com; helo=ipxbvo.tcif.telstra.com.au
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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, W3C_NW=0.5
X-W3C-Scan-Sig: titan.w3.org 1cY4RH-00041k-54 b96eb8c5c8d9d04be4911eea7cf2cc16
X-Original-To: ietf-http-wg@w3.org
Subject: RE: aes128gcm: why verify padding?
Archived-At: <http://www.w3.org/mid/SYXPR01MB16153632AEC9FCA5889C9EB1E54B0@SYXPR01MB1615.ausprd01.prod.outlook.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33391
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
My though experiment was to have a very simply situation: a key and a counter to use as the nonce. To send a message in, say, 3 AEAD parts use nonces 1, 2, 3; to send the next message in, say, 2 parts use nonces 4 & 5; and the next message in 1 part uses nonce 6. As long as records that start a message are flagged (1, 4, & 6 here) and records that end a message are flagged (3, 5, & 6 here) I think this simple scheme can work: a receiver can tell when a bunch of records are an authentic sequence (prefix, suffix, or in the middle); though not when separate sequences are part of the same message without joining them (no start/end flags in between). Using XOR, instead of +, can still work; but a receiver can only really authenticate from the start. Using the KDF seems to mean: you know records are part of the same message (same salt); you know a record's position (even if using XOR, not +); you know where the start is so you don't need to distinguish start & middle. A start/middle/end indicator is necessary for the simplest schemes. A not-end/end indicator is sufficient for the aes128gcm scheme, thanks to the KDF. My judgement is that start/middle/end is more generic, with very little extra complexity (but if I'm in the rough so be it). -- James Manger -----Original Message----- From: Martin Thomson [mailto:martin.thomson@gmail.com] Sent: Monday, 30 January 2017 2:20 PM To: Manger, James <James.H.Manger@team.telstra.com> Cc: ilariliusvaara@welho.com; ietf-http-wg@w3.org Subject: Re: aes128gcm: why verify padding? On 30 January 2017 at 13:30, Manger, James <James.H.Manger@team.telstra.com> wrote: >> Actually, if you don't use KDF to obtain the nonce base together with >> the key, attacker can corrupt messages unless you actually verify that >> the start block is in its proper place. > > Is this because the scheme uses Nonce XOR Index (not Nonce + Index)? Not exactly. The theoretical attack (if I understood Ilari correctly) is if you had an explicit nonce on each record. For instance, the nonce is the first 12 octets of the ciphertext. At that point, an attacker would be more capable of performing interchanging any two records. That's different to your concern regarding dropping of some number of records and producing a valid sequence of records. Even assuming that you find an input that produces the same key while allowing you to control the nonce, you would be stuck with the interesting problem of finding a pattern of records that fit the XOR pattern. If there were only two records, dropping the first is trivial. If there were three records and you wanted to keep two of them, you have to switch the second and third to fit the pattern, which would run afoul of the padding delimiter check. Given that you would know the key at this point, I'd suggest that constructing a new message would be easier. > Given 2 valid AEADs, you can get the XOR of their indices but that isn't enough to tell how far apart they are in a sequence. It isn't even sufficient to tell that one comes right before the other. Hence, you really need to get the AEAD marked "start" first (or get the salt from which the "start" record's nonce is derived). Are you saying that you can feed random data into your oracle until it accepts two records? And that you used the same key to generate that random data? Assuming those preconditions, I agree that you can get the XOR of the indices of these records. But you must have known those indices because the oracle we're designing only accepts records at those indices. Even if you could do what you suggest (with a different oracle perhaps), I think that you are right in suggesting that that isn't much use. You have just won every lottery on the planet in the same week, and still that information doesn't seem very useful.
- aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Ilari Liusvaara
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Ilari Liusvaara
- RE: aes128gcm: why verify padding? Manger, James
- Re: aes128gcm: why verify padding? Martin Thomson
- RE: aes128gcm: why verify padding? Manger, James