Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01

"David McGrew (mcgrew)" <> Mon, 12 November 2012 23:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8440321F8786 for <>; Mon, 12 Nov 2012 15:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.556
X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hnD-Y5pXAwGq for <>; Mon, 12 Nov 2012 15:39:35 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 983F221F8674 for <>; Mon, 12 Nov 2012 15:39:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2468; q=dns/txt; s=iport; t=1352763575; x=1353973175; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=CfhQMd/wi5U9Z3cUDSDgdUCOlZv597bwG8WrdKDjZ5k=; b=RShkj5zpEIguV6Gn6a3VlEY4f/bSR7ey/HTqWfU6xcB2wi25fyK+yNX7 kxBE/Oxg095o51+vnFj3NuFR9AVTMUjsqFFN0/x3fAvV8rejdJmTWRg1d PE2kxLsBBGkTLIi9BBnKpVJPYfUkF1Pt+k3sLqQVZWaGEzkMyEXrbeTzU 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="141455826"
Received: from ([]) by with ESMTP; 12 Nov 2012 23:39:35 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id qACNdY8V000976 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 Nov 2012 23:39:35 GMT
Received: from ([]) by ([]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 17:39:34 -0600
From: "David McGrew (mcgrew)" <>
To: Dan Harkins <>
Thread-Topic: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
Thread-Index: AQHNwRNEN8doFmnIpEGgEt2l6seQrpfm7JkA
Date: Mon, 12 Nov 2012 23:39:33 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--40.253500-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Mon, 12 Nov 2012 22:26:20 -0800
Cc: Mike Jones <>, "" <>, "" <>
Subject: Re: [jose] [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA, version 01
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Nov 2012 23:39:36 -0000

On 11/12/12 3:21 PM, "Dan Harkins" <> wrote:

>  Hi Mike,
>> From: Mike Jones
>> <<>>
>> Date: Monday, November 12, 2012 1:55 PM
>> To: Cisco Employee <<>>,
>> "<>"
>> <<>>,
>> "<>"
>> <<>>
>> Subject: RE: [Cfrg] Authenticated Encryption with AES-CBC and HMAC-SHA,
>> version 01
>> As background, if there was a version of this spec that did not assume
>> that the parameters would be concatenated together in a specific way,
>> left them as independent inputs and outputs, as AES GCM and AES CTR do,
>> would be a better match for JOSE¹s use case.
>  I encourage you to look into SIV mode, an AEAD scheme found in
>RFC 5297. SIV was defined by Rogaway and Shrimpton (in a paper
>found in the RFC) and is provably secure.
>  It takes a vector of input as additional authenticated data which will
>be authenticated, and a plaintext which will be authenticated and
>encrypted. It does not assume that the parameters are concatenated
>together, it's just a vector of separate inputs.
>  Additionally, SIV mode does not require a random IV/nonce. It works
>just fine if you have one, and it won't collapse if it is repeated (as GCM
>does) or is predictable (as CBC-HMAC does), and it works if you don't
>have, or want to have, one. In that fashion it is more robust than other
>AEAD schemes. The downside is that it's slower than GCM but is probably
>faster than CBC-HMAC with SHA2.

AES-SIV is in several ways technically superior to AES-CBC-HMAC-SHA.
However, the motivation to use the latter algorithm is its widespread
availability, as I understand it.   Mike and some other folks did a survey
of what crypto that is available.  (Perhaps someone can send a reference,
it is a good survey.)

Despite SIV's flexibility, it doesn't address Mike's complaint, because it
does not have an authentication tag that is separate from the ciphertext.
 Instead, it has the synthetic IV (which acts like an auth tag) combined
with the ciphertext.

As an aside, if SIV is used for JOSE, it can use the RFC 5116 interface
(see Sections 6.1-6.3 of the SIV RFC) and essentially would need to do so.


>  regards,
>  Dan.