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