Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key

John Bradley <> Mon, 12 November 2012 01:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id ABB8F21F84C4 for <>; Sun, 11 Nov 2012 17:54:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BR5shopZwOhA for <>; Sun, 11 Nov 2012 17:54:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A3E3521F84B3 for <>; Sun, 11 Nov 2012 17:54:12 -0800 (PST)
Received: by with SMTP id i4so1154757ggn.31 for <>; Sun, 11 Nov 2012 17:54:12 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=6bEaFTIO9OnRum2ysgjYo+oBnH11KFJ7jnpBftCqDsM=; b=cnpEAnBBwhjFdcCI5yXJJ1XQXYpe1cfxq5+snPwMz18ozzjML+MbrOXTTVpdflk9JV vkC2qUnR285ePcncLM+u8hJbX/dCDo0bAZDbR2sdFXgVDLKcmuEcFTTZQzczGBBYsLU9 WR266jpKuly6UM8KlZS8UlQg62Alu+wvJow2BdUbdRJ0/p0TKXq/3cEQ22u6PwGTvDhU H8OUSV5s/8pZ+ezEb+omB7QVEwNCdg/OT2jQt5vLvVKVryLsvgf13NkIFOMBhAKF7RUL 6m8DzpbzqJmfmdtgpPHi3dpSWfKtRzN0pfUqbTb5RgG/JImXr9gV0eEuZ3jXfWPTGLX7 lUCA==
Received: by with SMTP id e46mr17930693yhc.57.1352685252033; Sun, 11 Nov 2012 17:54:12 -0800 (PST)
Received: from [] ( []) by with ESMTPS id t14sm4852036anl.17.2012. (version=TLSv1/SSLv3 cipher=OTHER); Sun, 11 Nov 2012 17:54:11 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_431A62DE-0493-43B8-BDC8-4D2F43D3E425"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley <>
In-Reply-To: <BAY171-W1363D7DE3972B29DE2DC221B76D0@phx.gbl>
Date: Sun, 11 Nov 2012 22:54:00 -0300
Message-Id: <>
References: <BAY171-W32DD53461B3DF4235F053DB7680@phx.gbl>, <> <BAY171-W1363D7DE3972B29DE2DC221B76D0@phx.gbl>
To: Michael Jones <>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQl/Q0a50/Jp/HTykTk6LOb2c/kTa/9DHF7O6Dez80NAyAaGuWS0re6fnktIVYYqCUpz5gHn
Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key
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 01:54:13 -0000

Sorry I was only thinking of the KDF issue not the other differences.   You far correct there are still non trivia differences between the two.

The two are closer but not the same.  

I caught the flue on my way home from IETF and probably need to get off the cold medication before answering email.

On 2012-11-11, at 10:30 PM, Michael Jones <> wrote:

> Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1).  For instance, as was discussed after David's presentation at IETF 84, draft-mcgrew-aead-aes-cbc-hmac-sha2 does not follow the pattern of AEAD algorithms such as AES GCM, which have two inputs (plaintext, "additional authenticated data"), and two outputs (ciphertext, "authentication tag").  Instead, it adds a step combining the ciphertext and "authentication tag" outputs.
> If you read the draft, implementation of draft-mcgrew-aead-aes-cbc-hmac-sha2 has a lot more steps than what we have for A128CBC+HS256 and A256CBC+HS512.  It requires generating and adding specific padding bytes.  It prefixes the ciphertext with the IV.  It includes the length of the "additional authenticated data" in the MAC calculation.  It combines the two outputs into one.  For decryption, likewise, the two outputs must be split apart, the IV must be split apart, etc.
> All of these are steps that implementations could get wrong, resulting in interoperability problems.  By keeping all the parameters separate, our current A128CBC+HS256 and A256CBC+HS512 algorithms eliminate those steps.
> I'm sorry for the apparent confusion between (1) and draft-mcgrew-aead-aes-cbc-hmac-sha2.  While they both explicitly represent the CMK and CEK, and use the same underlying crypto operations, the details differ in ways that are likely to matter to implementers.  If there was a version of draft-mcgrew-aead-aes-cbc-hmac-sha2 that kept all the inputs and outputs separate, I agree that it would be a reasonable candidate for JOSE to consider.  But unlike AES GCM, that's not what it does.
> -- Mike
> > From:
> > To:;
> > Date: Mon, 12 Nov 2012 09:23:37 +1100
> > Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key
> > 
> > > So I’d like to explicitly ask the working group. Do you want us to:
> > >
> > > (1) Use the concatenation of random CEK and CIK values as the CMK for AES CBC, resulting in a longer CMK?
> > > (2) Continue to use a KDF to generate the CEK and CIK from a shorter CMK?
> > 
> > 
> > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2
> > 
> > --
> > James Manger
> _______________________________________________
> jose mailing list