Re: aes128gcm: why verify padding?
Martin Thomson <martin.thomson@gmail.com> Mon, 30 January 2017 03:22 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 14608120726 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 29 Jan 2017 19:22:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.719
X-Spam-Level:
X-Spam-Status: No, score=-9.719 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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, RCVD_IN_SORBS_SPAM=0.5, 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 (2048-bit key) header.d=gmail.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 6ObR3YW6CA9B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 29 Jan 2017 19:22:48 -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 133DD126CD8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 29 Jan 2017 19:22:47 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1cY2W3-0004b6-6V for ietf-http-wg-dist@listhub.w3.org; Mon, 30 Jan 2017 03:20:27 +0000
Resent-Date: Mon, 30 Jan 2017 03:20:27 +0000
Resent-Message-Id: <E1cY2W3-0004b6-6V@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 <martin.thomson@gmail.com>) id 1cY2Vx-0004XT-L0 for ietf-http-wg@listhub.w3.org; Mon, 30 Jan 2017 03:20:21 +0000
Received: from mail-qk0-f176.google.com ([209.85.220.176]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <martin.thomson@gmail.com>) id 1cY2Vr-00064I-Fa for ietf-http-wg@w3.org; Mon, 30 Jan 2017 03:20:16 +0000
Received: by mail-qk0-f176.google.com with SMTP id u25so116633343qki.2 for <ietf-http-wg@w3.org>; Sun, 29 Jan 2017 19:19:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=kX4nTU9lMd6OeGy8lI4uNJGMKTj9OXHLTA2T/Wl7Zlk=; b=Pd1/tSWjZxyz+lxz5ZbgVGVtqDl3OdtaBImvW+d+2ejgAmbony/RYBfX04L2AhoSMV /CZH6w/lIE1a2hrXT8Qih/G5olU+1s6u2cX868V7vD+OMDKPR04EEkzujPw6Ylqi7jdY q571+nFzUuIqKbXw6VngJbBK8QIr/z6YDxQ/739fXy+3MhcZpmQqi+bS8bQPckorEaa7 Frmran0UhDZ2XfRFW0FzBjSlSRkUxfdCeKe/dK0TWGBU8yPVFWS9Pa0D3kfKr6ZrR9Jx BCMxU4aw9Sps4oeNbbhG06/LF9oq+oirOhkCkuRolitWmSkTZf9Ks+yGJZ6u96JrecyI 8NNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=kX4nTU9lMd6OeGy8lI4uNJGMKTj9OXHLTA2T/Wl7Zlk=; b=DFSq3M2eRTEAJe5aWo5oCarolglIlLmS8ynA4P8GSHJ8o/zXlpIqXYr4PX8/Wd+A0U pCRXo/u3RsUSg5xKe8eA3A0esHkipwTp9dilNmDnt6M3rH+trXifqKqcSfSW4L8fhjXY A83J1PiO487QAaeiLWzyg4ojXFbUQwuJEPW9RH2ntcHO6/4KHO489GgwyMdS9N8Pq5CO M0ib6pKFY4vgKAv84hmS5/RDOFBmZ/tWlSlZZJCy8p7TiaEEneYwUTgFOeCYUoj85/KB zMqnqrl8nHAnbLePC0qb1gfqwcJtWlwBcH9x/gInZCTFWyFoMduMNa2nTrJGDtWe6msu semA==
X-Gm-Message-State: AIkVDXJqCmG+RJ1fg2DXki6TAdn30SD2+KcGZuEbOSz74t9A1rwHqN/fTSu0U9AEt0wdxWNWKXja12lr5QyatQ==
X-Received: by 10.55.27.65 with SMTP id b62mr20811560qkb.202.1485746389497; Sun, 29 Jan 2017 19:19:49 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Sun, 29 Jan 2017 19:19:49 -0800 (PST)
In-Reply-To: <SYXPR01MB16157AC6FFBC54BA8A046AF6E54B0@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>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 30 Jan 2017 14:19:49 +1100
Message-ID: <CABkgnnXYc3V3FoVH_TsBUMZes5r3uZaTLs4zdFPXNMg178ppFw@mail.gmail.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>
Cc: "ilariliusvaara@welho.com" <ilariliusvaara@welho.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=209.85.220.176; envelope-from=martin.thomson@gmail.com; helo=mail-qk0-f176.google.com
X-W3C-Hub-Spam-Status: No, score=-6.3
X-W3C-Hub-Spam-Report: AWL=0.338, 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, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1cY2Vr-00064I-Fa 57aa2a4c4d248851bde77751a39d780c
X-Original-To: ietf-http-wg@w3.org
Subject: Re: aes128gcm: why verify padding?
Archived-At: <http://www.w3.org/mid/CABkgnnXYc3V3FoVH_TsBUMZes5r3uZaTLs4zdFPXNMg178ppFw@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/33389
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>
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