Re: [TLS] Data volume limits

Andrey Jivsov <crypto@brainhub.org> Wed, 16 December 2015 00:39 UTC

Return-Path: <crypto@brainhub.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E75D41A00AC for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 16:39:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham
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 EBZiQ6a8GoZu for <tls@ietfa.amsl.com>; Tue, 15 Dec 2015 16:39:46 -0800 (PST)
Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D026C1A00A3 for <tls@ietf.org>; Tue, 15 Dec 2015 16:39:46 -0800 (PST)
Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-04v.sys.comcast.net with comcast id u0fG1r0025AAYLo010fmtk; Wed, 16 Dec 2015 00:39:46 +0000
Received: from [IPv6:::1] ([73.170.34.26]) by resomta-po-15v.sys.comcast.net with comcast id u0fl1r0060ZpzqZ010flVD; Wed, 16 Dec 2015 00:39:46 +0000
Message-ID: <5670B2D1.7050201@brainhub.org>
Date: Tue, 15 Dec 2015 16:39:45 -0800
From: Andrey Jivsov <crypto@brainhub.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: tls@ietf.org
References: <CABcZeBNR76DqPo0Mukf5L2G-WBSC+RCZKhVGqBZq=tJYfEHLUg@mail.gmail.com> <e007baa2f53249d49917e6023e578bc0@XCH-RTP-006.cisco.com> <CACsn0ckSo-affRmsTZaodCJZsFisPygnhk9=OZuV0_9SVMbUxQ@mail.gmail.com> <6674a4ec51fe4e158929bf429260d6ea@XCH-RTP-006.cisco.com> <CABcZeBNSHGGwM41c9QS0G-pnsEkuyA-q6FMhMgv2NQBDmwWwqA@mail.gmail.com> <5670AB96.9000602@streamsec.se>
In-Reply-To: <5670AB96.9000602@streamsec.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1450226386; bh=E8a3V6U5MgvkxeD3gsd3hi3S1LuKAFJr2aixGssORKc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=QMFK76cH+mky71LjvlKBmwVvrmUVl0og6/yas46FIy8jurEkIHPhfnwRSZNymDaVG SUl41rAnCHs5ryVLs3ZtyJtXOHTgqIghWT5VNgcjzkrdWnaWNEdAhquRSfPWT3GaFe RR2HNw72btK8yW184AZwvQdZwftSUZmseY75URFwZwih247nHt77b+ZpczDJAQT9pM fA5fMsIo1oLg6Nb17cV66Ij/cLloYLzopqVcyilT+Hy6doN8lfCHxBxw/G3dwf+6CO QkyUbl4ZLoNobjlYK8FZjwLoZzGjL2uRrnBMhf6QEgKcNfzJOtDal5kDEpTjzDz3BY KoZmZ49SCzC7g==
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/2ln0efxpFzjCUqLsAd1xZIbxej8>
Subject: Re: [TLS] Data volume limits
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 16 Dec 2015 00:39:49 -0000

On 12/15/2015 04:08 PM, Henrick Hellström wrote:
 > On 2015-12-16 00:48, Eric Rescorla wrote:
 >>
 >>
 >> On Tue, Dec 15, 2015 at 3:08 PM, Scott Fluhrer (sfluhrer)
 >> <sfluhrer@cisco.com <mailto:sfluhrer@cisco.com>> wrote:
 >>     The quadratic behavior in the security proofs are there for just
 >>     about any block cipher mode, and is the reason why you want to stay
 >>     well below the birthday bound.
 >>
 >>
 >> The birthday bound here is 2^{64}, right?
 >>
 >> -Ekr
 >>
 >>        However, that's as true for (say) CBC mode as it is for GCM
 >
 > Actually, no.
 >
 > Using the sequence number as part of the effective nonce, means that 
it won't collide. There is no relevant bound for collisions in the 
nonces or in the CTR state, because they simply won't happen (unless 
there is an implementation flaw). There won't be any potentially 
exploitable collisions.
 >

Here is one attack that exploits such a collision 
https://www.ietf.org/mail-archive/web/openpgp/current/msg08345.html

 > However, theoretically, the GHASH state might collide with a 2^{64} 
birthday bound. This possibility doesn't seem entirely relevant, though.
 >
 > _______________________________________________
 > TLS mailing list
 > TLS@ietf.org
 > https://www.ietf.org/mailman/listinfo/tls