Return-Path: X-Original-To: jose@ietfa.amsl.com Delivered-To: jose@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABB8F21F84C4 for ; Sun, 11 Nov 2012 17:54:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: 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 mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BR5shopZwOhA for ; Sun, 11 Nov 2012 17:54:12 -0800 (PST) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A3E3521F84B3 for ; Sun, 11 Nov 2012 17:54:12 -0800 (PST) Received: by mail-gg0-f172.google.com 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; d=google.com; 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 10.236.52.198 with SMTP id e46mr17930693yhc.57.1352685252033; Sun, 11 Nov 2012 17:54:12 -0800 (PST) Received: from [192.168.1.211] (190-20-39-87.baf.movistar.cl. [190.20.39.87]) by mx.google.com with ESMTPS id t14sm4852036anl.17.2012.11.11.17.54.08 (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: Date: Sun, 11 Nov 2012 22:54:00 -0300 Message-Id: <95B94292-42F7-4C57-B6FD-B509373F9E98@ve7jtb.com> References: , <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com> To: Michael Jones X-Mailer: Apple Mail (2.1499) X-Gm-Message-State: ALoCoQl/Q0a50/Jp/HTykTk6LOb2c/kTa/9DHF7O6Dez80NAyAaGuWS0re6fnktIVYYqCUpz5gHn Cc: james.h.manger@team.telstra.com, jose@ietf.org Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key X-BeenThere: jose@ietf.org 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 --Apple-Mail=_431A62DE-0493-43B8-BDC8-4D2F43D3E425 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 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. =20 I caught the flue on my way home from IETF and probably need to get off = the cold medication before answering email. John 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. > =20 > 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. > =20 > 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. > =20 > 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. > =20 > -- Mike > =20 > > From: James.H.Manger@team.telstra.com > > To: michael_b_jones@hotmail.com; jose@ietf.org > > 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 > >=20 > > > So I=92d 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? > >=20 > >=20 > > 1. Use draft-mcgrew-aead-aes-cbc-hmac-sha2 > >=20 > > -- > > James Manger > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose --Apple-Mail=_431A62DE-0493-43B8-BDC8-4D2F43D3E425 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 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.

John
On 2012-11-11, at = 10:30 PM, Michael Jones <michael_b_jones@hotmail.com> 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: James.H.Manger@team.telstr= a.com
> To: michael_b_jones@hotmail.com; jose@ietf.org
> 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=92d 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
_______________________________________________
j= ose mailing list
jose@ietf.org
https://www.ietf.org/ma= ilman/listinfo/jose

= --Apple-Mail=_431A62DE-0493-43B8-BDC8-4D2F43D3E425--