Hi Mike, Please see <DAM> inline.
From: Michael Jones <michael_b_jones at hotmail.com> To: <james.h.manger at team.telstra.com>, <jose at ietf.org> Date: Sun, 11 Nov 2012 17:30:54 -0800 In-reply-to: <255B9BB34FB7D647A506DC292726F6E11500331CA9 at WSMSG3153V.srv.dir.telstra.com> References: <BAY171-W32DD53461B3DF4235F053DB7680 at phx.gbl>, <255B9BB34FB7D647A506DC292726F6E11500331CA9 at WSMSG3153V.srv.dir.telstra.com> List-id: Javascript Object Signing and Encryption <jose.ietf.org> 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. <DAM> draft-mcgrew-aead-aes-cbc-hmac-sha2 does use exactly the same interface as AES-GCM, RFC 5116, and the other AEAD algorithms that make use of that interface. To make this more clear, I can make the following addition. Section 2.1 starts out as "We briefly recall the encryption interface defined in Section 2 of [RFC5116]." I will add "which is used by all of the algorithms defined in this note". </DAM> 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. <DAM> draft-mcgrew-aead-aes-cbc-hmac-sha2 has all of the required steps for authenticated encryption, and does not have any extraneous steps. Things like plaintext padding need to be specified, and it is critical to have the length of the associated data included in the MAC input (see Section 6, third paragraph, of draft-mcgrew). The fact that implementations might get these details wrong is why they belong in the crypto algorithm, and not in the JOSE implementation. Consider, for instance, that with the AEAD approach these details would get test coverage from the AEAD test cases; otherwise, there are details that would go untested. </DAM> 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. <DAM> When JOSE met at IETF84, the consensus of the room was to use AEAD and draft-mcgrew-aead-aes-cbc-hmac-sha2, and omit unauthenticated encryption. That's what JOSE should do, as it is the technically best solution. I will ask Kevin Igoe to move draft-mcgrew forward to RFC. </DAM> 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. <DAM> draft-mcgrew-aead-aes-cbc-hmac-sha2 uses the same interface as does AEAD_AES_128_GCM; see Section 5.1 of RFC 5116. David </DAM> -- Mike > From: James.H.Manger at team.telstra.com > To: michael_b_jones at hotmail.com; jose at 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 [email protected] https://www.ietf.org/mailman/listinfo/jose
