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

"Dan Harkins" <> Tue, 13 November 2012 00:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5A59021F8782 for <>; Mon, 12 Nov 2012 16:06:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.265
X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 74z-4so2nBct for <>; Mon, 12 Nov 2012 16:06:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id BFEF421F875C for <>; Mon, 12 Nov 2012 16:06:44 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id 42DAB1022400A; Mon, 12 Nov 2012 16:06:44 -0800 (PST)
Received: from (SquirrelMail authenticated user by with HTTP; Mon, 12 Nov 2012 16:06:44 -0800 (PST)
Message-ID: <>
In-Reply-To: <>
References: <>
Date: Mon, 12 Nov 2012 16:06:44 -0800
From: Dan Harkins <>
To: "David McGrew (mcgrew)" <>
User-Agent: SquirrelMail/1.4.14 [SVN]
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Mailman-Approved-At: Mon, 12 Nov 2012 22:26:20 -0800
Cc: Mike Jones <>, "" <>, Dan Harkins <>, "" <>
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: Tue, 13 Nov 2012 00:06:45 -0000

  Hi David,

On Mon, November 12, 2012 3:39 pm, David McGrew (mcgrew) wrote:
> 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.)

  Well, there is no widespread availability of AES-CBC-HMAC-SHA either.
There may be availability of AES-CBC and HMAC-SHA separately but then
there is, probably, availability of AES-CTR and AES-CMAC too and that
is all SIV is, a provably secure construction of those two primitives.

> 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.

  Ahh, I missed that. But I think that is probably a trivial complaint of
any 5116 AEAD scheme. It should be straightforward to extract the
specific sub-string from the bitstring returned by any of the appropriate
schemes if he wants to copy the IV/MAC/tag/whatever into a field that
is separate from the encrypted plaintext.

> 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.

  Good point!



> David
>>  regards,
>>  Dan.