Re: [TLS] Pull Request: Removing the AEAD explicit IV

Adam Langley <> Tue, 17 March 2015 18:21 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1513B1A884F for <>; Tue, 17 Mar 2015 11:21:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id P6dcaInMdDUu for <>; Tue, 17 Mar 2015 11:21:27 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A766D1A8846 for <>; Tue, 17 Mar 2015 11:21:26 -0700 (PDT)
Received: by labjg1 with SMTP id jg1so16133182lab.2 for <>; Tue, 17 Mar 2015 11:21:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7JHt79PbRPo8Mpi5ZLP03UV7IoO7uZSKlS55J236Kps=; b=O0mM0CQCvEEwAj0VrMszqXip5t/Mls6TBKwnQoc74QQFnsRn+P7YSw86cAuC3zwnPG cqzODdN0wdgXZkMzv0hRt6NkGAhGU3fQH1AVNGWNEpfczRQcgJUIJXfoc1cb+irHhllE 5r9W7t2njzhlkoU7quvMh11bj9oGiBDwiXeRTNFGCbSIqj116YgUcZhccFh70WTptjge 1p5wH3jIKorh3JZqpOdHsDIscUTU8DUXH0eyae8hwyw7O5CY5MzsEBI2I9Dv2LcpdOuv UDMJKHvhdp7mDlf/3dcZk2Lq66FfLRRqVmwkYqQI61Dj1glcSnd4QF2I6tsICQu+iuJz 4Mhw==
MIME-Version: 1.0
X-Received: by with SMTP id dy5mr61647107lac.57.1426616485127; Tue, 17 Mar 2015 11:21:25 -0700 (PDT)
Received: by with HTTP; Tue, 17 Mar 2015 11:21:24 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 17 Mar 2015 11:21:24 -0700
X-Google-Sender-Auth: bzuD1TiPS56BZAcpmrt8d3pvdEg
Message-ID: <>
From: Adam Langley <>
To: Michael StJohns <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Pull Request: Removing the AEAD explicit IV
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: Tue, 17 Mar 2015 18:21:28 -0000

On Tue, Mar 17, 2015 at 11:06 AM, Michael StJohns
<> wrote:
> That works for the currently defined pure AEAD modes (CCM/GCM at least,
> haven't looked at chacha).   Will that work in all cases for constructed
> AEAD modes?  (e.g. where we build an AEAD mode out of an encryption mode and
> an integrity mode and derive the E and I keys from a single key internal to
> the constructed mode - say  AES-CBC with CMAC for example).  Short answer is
> probably not.

I believe that it will, although I welcome counterexamples.

The AEAD interface requires only an nonce (i.e. unique, but not
unpredictable) and, under this proposal, that's all that TLS will

CBC modes require an IV (i.e. unpredictable). If you wished to make an
AES-CBC-HMAC-SHA256 AEAD, for example, then you would do something
like this:

Define the key length to be twice as large as the AES key and split it
internally into a CBC key and an IV key. For each record, generate the
IV by AES(key = IV_key, block = nonce) then encrypt the plaintext
using CBC with that IV and the CBC key. (And you might need extra key
bytes for the HMAC too, but that's beside the point here.) Basically
you can generate the IVs using AES-CTR as a PRNG.