Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key
Stephen Farrell <stephen.farrell@cs.tcd.ie> Mon, 12 November 2012 13:14 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 8C1E721F859D for <jose@ietfa.amsl.com>; Mon, 12 Nov 2012 05:14:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 sPA1o7g9YgcN for <jose@ietfa.amsl.com>; Mon, 12 Nov 2012 05:14:05 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id B061C21F859E for <jose@ietf.org>; Mon, 12 Nov 2012 05:14:04 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 06A0EBE4D; Mon, 12 Nov 2012 13:13:41 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq-01WIwoYIE; Mon, 12 Nov 2012 13:13:39 +0000 (GMT)
Received: from [10.87.48.10] (unknown [86.41.57.92]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E490EBE47; Mon, 12 Nov 2012 13:13:38 +0000 (GMT)
Message-ID: <50A0F602.7080709@cs.tcd.ie>
Date: Mon, 12 Nov 2012 13:13:38 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121028 Thunderbird/16.0.2
MIME-Version: 1.0
To: Michael Jones <michael_b_jones@hotmail.com>
References: <BAY171-W32DD53461B3DF4235F053DB7680@phx.gbl>, , <255B9BB34FB7D647A506DC292726F6E11500331CA9@WSMSG3153V.srv.dir.telstra.com>, <BAY171-W1363D7DE3972B29DE2DC221B76D0@phx.gbl>, <255B9BB34FB7D647A506DC292726F6E1150045CB9F@WSMSG3153V.srv.dir.telstra.com> <BAY171-W60127476E05F5FB49EDA0FB76D0@phx.gbl>
In-Reply-To: <BAY171-W60127476E05F5FB49EDA0FB76D0@phx.gbl>
X-Enigmail-Version: 1.4.5
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
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 <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 12 Nov 2012 13:14:09 -0000
FWIW, I'd say asking David and/or CFRG about stuff like this ought be useful. Features that are a "don't care" from the jose WG/protocol perspective might well be important either for security reasons or because of re-use in other protocols. S. On 11/12/2012 03:15 AM, Michael Jones wrote: > > I'm not sure why you're saying that combing fields with distinct meanings is good design. It just means extra, unnecessary steps. The pattern used by AES GCM, which keeps fields with distinct meanings separate, seems more general and cleaner to me. I think this may be one of those points where we may just have to agree to disagree, because it doesn't seem that that either of us is convincing the other. ;-) > Cheers,-- Mike From: James.H.Manger@team.telstra.com > To: michael_b_jones@hotmail.com; jose@ietf.org > Date: Mon, 12 Nov 2012 14:06:46 +1100 > Subject: Re: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key > >> Using draft-mcgrew-aead-aes-cbc-hmac-sha2 is not the same thing as (1). Then change my vote to: (1b) Use draft-mcgrew-aead-aes-cbc-hmac-sha2 I know draft-mcgrew-aead-aes-cbc-hmac-sha2 is not quite the same as A128CBC+HS256-without-a-KDF. There are a handful of “distinctions-without-a-difference” and some differences that are subtle but important where draft-mcgrew is better. > It requires generating and adding specific padding bytes. They both add identical padding. draft-mcgrew spells it out; A128CBC+HS256 just refers to PKCS #5 padding (without much of a reference). > It prefixes the ciphertext with the IV. Good design. But if JOSE insists on separate B64-encoded fields it is trivial to convert. > It includes the length of the "additional authenticated data" in the MAC calculation. Great design. A128CBC+HS256, in contrast, relies on an extra B64-encoding step to safely distinguish “additional data” and “ciphertext”. A128CBC+HS256 has to MAC up to 33% more bytes than dra ft-mcgrew (when the plaintext size dominates). While general-purpose crypto libraries only implement the AES & HMAC components but not the AEAD combination (and A128CBC+HS256 is only applied to small messages), it doesn’t matter much. However, once crypto libraries offer AEAD APIs it does. A128CBC+HS256 requires the “inside” of the crypto API to have the raw and B64 data but only one form will be passed across the API. That locks in duplicated effort and overhead so much so that I expect general purpose crypto libraries will support draft-mcgrew but not A128CBC+HS256. > It combines the two outputs into one. Again good design, but trivial to separate if desired. Both JWA and draft-mcgrew refer to RFC 5116 “An Interface and Algorithms for Authenticated Encryption”. JOSE should follow the pattern specified in that RFC, which draft-mcgrew does. --James Manger From: Michael Jones [mailto:michael_b_jones@hotmail.com] > Sent: Monday, 12 November 2012 12:31 PM > To: Manger, James H; jose@ietf.org > Subject: RE: [jose] Choice for WG: Use a KDF with AES CBC or use a longer key 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.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 >> >>> 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 > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose > > > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose >
- [jose] Choice for WG: Use a KDF with AES CBC or u… Michael Jones
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Axel Nennker
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Michael Jones
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Manger, James H
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Manger, James H
- Re: [jose] Choice for WG: Use a KDF with AES CBC … John Bradley
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Manger, James H
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Michael Jones
- Re: [jose] Choice for WG: Use a KDF with AES CBC … John Bradley
- Re: [jose] Choice for WG: Use a KDF with AES CBC … John Bradley
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Michael Jones
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Stephen Farrell
- [jose] Choice for WG: Use a KDF with AES CBC or u… David McGrew (mcgrew)
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Michael Jones
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Richard L. Barnes
- Re: [jose] Choice for WG: Use a KDF with AES CBC … Mike Jones