Re: [TLS] Data Volume Limits Analysis
Atul Luykx <Atul.Luykx@esat.kuleuven.be> Fri, 29 April 2016 15:43 UTC
Return-Path: <atul.luykx@esat.kuleuven.be>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FA5312B039 for <tls@ietfa.amsl.com>; Fri, 29 Apr 2016 08:43:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.196
X-Spam-Level:
X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.996] autolearn=ham autolearn_force=no
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 pSfpkjf_kART for <tls@ietfa.amsl.com>; Fri, 29 Apr 2016 08:43:00 -0700 (PDT)
Received: from cavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D585412B02C for <tls@ietf.org>; Fri, 29 Apr 2016 08:42:59 -0700 (PDT)
X-KULeuven-Envelope-From: atul.luykx@esat.kuleuven.be
X-KULeuven-Scanned: Found to be clean
X-KULeuven-ID: 635F812827D.A23D3
X-KULeuven-Information: Katholieke Universiteit Leuven
Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 635F812827D; Fri, 29 Apr 2016 17:42:57 +0200 (CEST)
Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 6126E40AC; Fri, 29 Apr 2016 17:42:54 +0200 (CEST)
Received: from cobalt.esat.kuleuven.be (cobalt.esat.kuleuven.be [134.58.56.187]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 5CC5A6002E; Fri, 29 Apr 2016 17:42:54 +0200 (CEST)
Received: from webmail.esat.kuleuven.be (localhost [127.0.0.1]) by cobalt.esat.kuleuven.be (Postfix) with ESMTP id 59E6040; Fri, 29 Apr 2016 17:42:54 +0200 (CEST)
Received: from marckloff.esat.kuleuven.be ([10.33.137.112]) by webmail.esat.kuleuven.be with HTTP (HTTP/1.1 POST); Fri, 29 Apr 2016 17:42:54 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
Date: Fri, 29 Apr 2016 17:42:54 +0200
X-Kuleuven: This mail passed the K.U.Leuven mailcluster
From: Atul Luykx <Atul.Luykx@esat.kuleuven.be>
To: Martin Thomson <martin.thomson@gmail.com>
In-Reply-To: <CABkgnnXxkhP7z3XoGPa_G-DdzPx+cV_GWuZn4gAMRMrSNWvQwg@mail.gmail.com>
References: <78f6d6778c608a99e276c2efa561d2ab@esat.kuleuven.be> <CABkgnnXxkhP7z3XoGPa_G-DdzPx+cV_GWuZn4gAMRMrSNWvQwg@mail.gmail.com>
Message-ID: <d3dc9aa05ec2bf9a8f6e6f4aac6bf3ce@esat.kuleuven.be>
X-Sender: aluykx@esat.kuleuven.be
User-Agent: ESAT webmail service, powered by Roundcube
X-Virus-Scanned: clamav-milter 0.99 at cobalt
X-Virus-Status: Clean
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/WVx25PKJBtMNu8RHuNHD4Be1lvM>
Cc: tls@ietf.org
Subject: Re: [TLS] Data Volume Limits Analysis
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Apr 2016 15:43:02 -0000
Hey Martin, You're right, this analysis works for any block cipher with 128 bit output that is "good enough" (a pseudorandom permutation), and so for all versions of AES regardless of the key size. Determining the appropriate key size for the block cipher relies on accounting for possible attacks against the block cipher itself, and estimating the computational power of the adversaries you want to protect against. You could also use formula (7) to recompute the bounds with a different block size (e.g. 64 bits). Atul On 2016-04-29 05:40, Martin Thomson wrote: > On 9 March 2016 at 09:16, aluykx <Atul.Luykx@esat.kuleuven.be> wrote: >> Kenny Paterson and I prepared a document providing an overview of how >> much >> data ChaCha20+Poly1305 and AES-GCM can process with a single key. >> Besides >> summarizing the results, the document also gives an explanation of why >> the >> limits are there. The document confirms the analysis done by Watson >> and >> others in the thread on "Data Volume Limits", but goes into more >> detail. > > Hi Atul, > > Just to confirm, but this analysis is for all variants of AES-GCM > regardless of key size? From formula (7) it shows that attack > probability is directly a function of block size and the number of > blocks. > > --Martin
- [TLS] Data Volume Limits Analysis aluykx
- Re: [TLS] Data Volume Limits Analysis Eric Rescorla
- Re: [TLS] Data Volume Limits Analysis aluykx
- Re: [TLS] Data Volume Limits Analysis Aaron Zauner
- Re: [TLS] Data Volume Limits Analysis Martin Thomson
- Re: [TLS] Data Volume Limits Analysis Atul Luykx