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

Axel Nennker <> Fri, 09 November 2012 18:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9C40B21F84EB for <>; Fri, 9 Nov 2012 10:48:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.598
X-Spam-Status: No, score=-4.598 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rCV4cg-L+Oqj for <>; Fri, 9 Nov 2012 10:48:33 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 76FEC21F84E6 for <>; Fri, 9 Nov 2012 10:48:33 -0800 (PST)
Received: by with SMTP id dr13so1920630wgb.13 for <>; Fri, 09 Nov 2012 10:48:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=oTpx/AuWX0N/2Zy4tvrQvTLC76IzOtW4N5GU1xY1qxk=; b=ikw5VX8zIrshjMA8Yd/3pXOR2ZRXM1jiM8fRpxQIwgUM4YLkrCCa03tWGnhvgRTgUz tEU+dXMcPsH6/IvhXgldYYowjhFauNcXY3U+kLIWGh1QrdQqWJWUK3eGfAXHJtBoPVSH AaZCKMoQVgLQoE16MJ95BEFR3JUK3Nv7vcsLbje90+P8zPWnjesZMw4HyLMLeECGOufI mhH71rErg3Ef7a6uClV0tK85BPa3VYNMxwq7VX8yq81T1BrpW8IaHFoE23MDX3kMKTGK VXSnIdLpYPLxcwNlr76r34eNjeiAkIxzqi5mHc1oCypXDzXEdTmKwxmDmnJ6SO7XHBOl OhBA==
MIME-Version: 1.0
Received: by with SMTP id v10mr4096993wiz.21.1352486912663; Fri, 09 Nov 2012 10:48:32 -0800 (PST)
Received: by with HTTP; Fri, 9 Nov 2012 10:48:32 -0800 (PST)
In-Reply-To: <BAY171-W32DD53461B3DF4235F053DB7680@phx.gbl>
References: <BAY171-W32DD53461B3DF4235F053DB7680@phx.gbl>
Date: Fri, 09 Nov 2012 19:48:32 +0100
Message-ID: <>
From: Axel Nennker <>
To: Michael Jones <>
Content-Type: multipart/alternative; boundary="f46d0444032efe224604ce1465de"
Cc: "" <>
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: Fri, 09 Nov 2012 18:48:34 -0000

My suggestion did not change the CMK size. I think it can stay as is.
I think that the concat-kdf is hard to  implement in Firefox/NSS in
Javascript if more than one iteration is needed. For the examples in the
spec there is no iteration and so there  is no problem.
There is a problem when NIST compliance is really required because CEK and
CIK should be computed in one go.
I could live with a NIST-like concat-KDF. I think openid connect even does
not need the  optional sender/receiver-ids.
Most important is the randomness of the CMK.

I don't understand the choices you provided. I think the CMK can stay a

// cmk size matters. more bytes give better cik and cek.
// cmk size does not change encodedEncryptedKeySegment if alg = RSA1_5 or
cmk = generateRandomKey(size, enc);
// cik and cek have as many bytes as required by enc
(cik,cek) = some-kdf(cmk, otherInfoInput);


2012/11/9 Michael Jones <>

>  Some working group members, including Axel, James, Matt, and Richard
> have expressed dissatisfaction with the use of the Concat KDF to generate
> the CEK and CIK when AES CBC is the block encryption algorithm.  Reasons
> stated are implementation complexity and possible issues with following the
> letter of the law of the NIST spec.  Axel and Richard had both written
> suggesting an alternative – let the CMK be simply the concatenation of the
> CEK and the CIK values.  This is the same approach used in
> draft-mcgrew-aead-aes-cbc-hmac-sha2.******
> ** **
> I and others had argued against this for size reasons.  For A128CBC+HS256
> this would increase the CMK size from 256 bits to 384 bits and for
> A256CBC+HS512 this would increase the CMK size from 512 bits to 768 bits.
> In the first case, after base64url encoding, one would expect the extra
> 128 bits to require about an extra 21 bytes in the JWE.  The interesting
> fact though, is that when an RSA algorithm is used to encrypt the CMK, the
> output size is same as the RSA key size – in our case, a minimum of 2048
> bits.  Thus, for any combination of “alg”:”RSA1_5” or “RSA-OAEP” and
> “enc”:”A128CBC+HS256” or “A256CBC+HS512” *there is no actual size
> difference in the JWE*.  (However when “alg”:”A128KW” or “A256KW” are
> used, there would be a size increase of about 21 or 43 bytes, respectively.)
> ****
> ** **
> 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?*
> ***
> ** **
>                                                             Thanks all,***
> *
>                                                             -- Mike****
> ** **
> P.S.  A KDF will still be required for ECDH-ES key agreement.  I’ll
> address James’ concerns about our use of Concat in a separate note.****
> _______________________________________________
> jose mailing list