Re: [TLS] Data volume limits

Aaron Zauner <> Fri, 01 January 2016 18:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 243AC1ACE39 for <>; Fri, 1 Jan 2016 10:25:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yKJVI6XMdIRt for <>; Fri, 1 Jan 2016 10:25:13 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 73D5A1ACE37 for <>; Fri, 1 Jan 2016 10:25:13 -0800 (PST)
Received: by with SMTP id l65so108607988wmf.1 for <>; Fri, 01 Jan 2016 10:25:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=FcDitDBx6Ub0TF+YWm0bVfQ1GgDUcG+d6r2waGG9YI8=; b=cpc22ccJBa+baaLYF50UG2XL6LnWdEJvQ+WFFE6VgIprlB/3VRbdsy5NZ87BDf/3L8 hgKOUqX5PKnbx5YZusFQC2sxvVrgTOVW6y7S5TADCuDUYBzkJ+k6NJWzhqpgyaLrCc1L 0HlREu2kp2Kw4b2TJBO5YS4Ai/txHRr605XmU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=FcDitDBx6Ub0TF+YWm0bVfQ1GgDUcG+d6r2waGG9YI8=; b=cJ3vQKADuPwYOTa9Ozl8ztaXpmReMBzBx6AtrHjVyZNWnOhlp1PQdHFKdd79KWHwCp TvX8fsrKUv6EbGYPehLDZ2FeVTsSMlWU4/nXYcIAe7ssAual1fDSFTz2gfx6xvljwYs/ TXXWdvPn+x/oo9UZYa8Q+GpEXhv++DD3x0iOQyTkYqyEpM7wMkso/1yW725fZ2eNFllV sIKNHh2FEYTmejntgolMScmBMn7r6fPhIkoFy6NBCNH7NgAF/uKCz1D+GbDE267+Gl6f V5fIBtlbxC2T05Kw6WYAIb+b5BsCEEddLqUY054fu+mCphTDfaDzJ4Mr0rV1+1GFnKAp 5kAQ==
X-Gm-Message-State: ALoCoQnTBLZ2qEdsx4Q4lNxfzpj32BnE/vQPkQs78QfcHd5hdIW0jhbSoTFp6kj260S7064dQpeqwNPVSSvM+0Pz+PusJKmqYQ==
X-Received: by with SMTP id n125mr86192488wma.103.1451672711994; Fri, 01 Jan 2016 10:25:11 -0800 (PST)
Received: from ( []) by with ESMTPSA id w80sm45101961wme.17.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Jan 2016 10:25:10 -0800 (PST)
Date: Fri, 1 Jan 2016 19:25:22 +0100
From: Aaron Zauner <>
Message-ID: <20160101191936.62107c1c1c@f374df84e9aa7e5>
References: <> <> <20160101073508.4dd10442c5@ebeb88ce88adeb8> <> <20160101165821.6cc8a962c4@1620a90cf4e0c0b> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="W/nzBZO5zC0uMSeA"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Subject: Re: [TLS] Data volume limits
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 01 Jan 2016 18:25:15 -0000


* <> [01/01/2016 18:19:26] wrote:
> The contention with GCM in this thread has been, so far, focused on
> confidentiality. This is because, by a result of Bernstein [1] (see also
> Appendix C of [2]), after q = 2^60 messages sent, plus q' = 2^60 attempted
> forgeries by an attacker with messages at most l_A = 2^16 blocks long, the
> probability of an attacker to forge a message is still ~2^-52. This does not
> present a data volume problem at the moment for the authentication part of

Interesting - I was not aware of that. Thanks for taking the time to

> On the other hand, after 2^60 OCB messages of 2^16 blocks (and thus 2^76
> total blocks), a block collision is almost guaranteed to have happened,
> enabling the aforementioned forgeries.

Sure. Would you see any way to improve this situation in the draft,
i.e. give implementation recommendations or similar?

> What you may be thinking of is the GCM behavior on _nonce reuse_. In this
> case, we are able to recover the authentication key by root finding and
> forge messages at will. This is also the case with OCB---on nonce reuse, we
> can forge any message that has the same checksum as a valid message.

No. Nonce-reuse is a seperate issue, the one I addressed in my
commit on the draft linked to in an earlier message. The
construction used in the chacha20/poly1305 draft is very elegant I
think: if you do not implement a proper nonce the implementation
will not interoperate with other implementation conforming to spec.

Thanks again,