Re: [jose] Use of AES-HMAC algorithm

["Manger, James H" <[e-mail]>]

I haven’t been at any of the meeting either! It is hard to track.

Java added AEAD support in v7 (eg javax.crypto.cipher#updateAAD).
OpenSSL has added AEAD support.
I think OpenSSL AEAD support has filtered into Ruby.
Apparently it hasn't filtered into node.js yet.
Microsoft Crypto Next Generation (Cng) has added AEAD support.
Go supports AE-without-the-AD, as does NaCl.

So I think JOSE will live long enough for explicit AEAD support in crypto libraries to be the norm.

--
James Manger


> -----Original Message-----
> From: Dick Hardt [mailto:[e-mail]]
> Sent: Thursday, 28 March 2013 2:32 PM
> To: Manger, James H
> Cc: Mike Jones; Jim Schaad; [e-mail]
> Subject: Re: [jose] Use of AES-HMAC algorithm
> 
> Thanks for taking the time to explain James. Not being at the meetings
> makes it tough to track.
> 
> My summary of what you said is that there are two different ways that
> have been proposed to use AES-CBC and HMAC-SHA: the one currently in
> the spec, and "David's algorithm".
> 
> FWIW as an implementer: none of the crypto libraries I have looked at
> are going to do D, E, & F for me; so I am doing them in my library and
> having them as separate fields vs yet-another-concatenation-algorithm
> is preferred. I can see why that would not be desirable if the format
> is then inconsistent with AEAD. Having said that, I'm coding in
> node.js, and even though it uses opensll that has AEAD, none of the
> AEAD interfaces are exposed currently in node.js, and I don't see that
> changing anytime soon => not sure AEAD is going to be incorporated with
> JWT libraries.
> 
> -- Dick
> 
> On Mar 27, 2013, at 7:49 PM, "Manger, James H"
> <[e-mail]> wrote:
> 
> > Dick,
> >
> > draft-mcgrew-aead-aes-cbc-hmac-sha2 "Authenticated Encryption with
> AES-CBC and HMAC-SHA" < http://tools.ietf.org/html/draft-mcgrew-aead-
> aes-cbc-hmac-sha2> is "David's algorithm".
> >
> >
> > Both draft-mcgrew-aead-aes-cbc-hmac-sha2 and "A128CBC+HS256" in JWA
> define a way to combine CBC and HMAC to get authenticated encryption.
> They make some different choices:
> >
> > A. Concatenate CBC & HMAC keys vs use a KDF to derive CBC & HMAC
> keys;
> >
> > B. 128+128 bit key sizes vs 128+256 bit keys size (for AES-128 &
> HMAC-256)
> >
> > C. Authentication tag half the hash size vs the full hash size
> >
> > D. Auth tag concatenated to ciphertext vs separate field
> >
> > E. IV concatenated with ciphertext vs separate field
> >
> > F. HMAC calculated over the raw ciphertext vs base64url-encoded
> ciphertext
> >
> > Mike is right that the crypto choices (A, B, C) will be more
> acceptable coming from the Crypto Forum Research Group (CRFG) group in
> a spec specifically describing CBC+HMAC (with security considerations
> and rationales for its choices, plus test vectors etc), compared to a
> JOSE-specific definition that is a small part of a JWA doc.
> >
> > D, E, & F are more to do with how the algorithms fit with crypto
> APIs. We will often have application code, JOSE library code, and
> crypto library code. The issues are which layers need to know which
> algorithm-specific details.
> >
> > Crypto libraries have historically offered CBC and HMAC interfaces.
> Now they are starting to offer AEAD interfaces. The CBC+HMAC algorithm
> we put in JOSE should be able to work well with AEAD interfaces. Draft-
> mgrew will work as it fits a model for AEAD algorithms defined in RFC
> 5116 "An Interface and Algorithms for Authenticated Encryption". The
> current JOSE-specific alg will NOT fit AEAD interfaces well --
> primarily because of difference F (that mixes app-layer base64url-
> encoding with a step that is internal to the AEAD algorithm).
> >
> > The authentication tag (difference D) is a subtler issue. A tag is a
> core component of a bunch of AEAD algorithms so some AEAD APIs have
> explicit support for a tag field. However it is really an internal
> detail: either the decryption hands back plaintext or it fails. A
> crypto library's implementation of an AEAD alg that has a tag needs to
> distinguish the tag from the rest of the ciphertext -- but does the
> app-layer need to distinguish the two? Not really.
> >
> >
> > I understand (and hope) the JOSE consensus is to go with draft-mcgrew
> on points A, B, C, and F.
> >
> > My opinion is that we should go with draft-mcgrew (and RFC5116) for D
> & E as well, but Mike (and others) disagree. It shouldn't affect the
> maths of the crypto, but it does affect APIs and the degree that the
> app layer can be (partially) relieved of the responsibility of dealing
> with some tough crypto issues (such as crypto-quality randomness,
> uniqueness of nonces etc).
> >
> > --
> > James Manger
> >