Re: [jose] Use of AES-HMAC algorithm

["Vladimir Dzhuvinov / NimbusDS" <[e-mail]>]

Hi guys,

I studied draft-mcgrew-aead-aes-cbc-hmac-sha2-01. It addresses the exact
same issue that we do with our JOSE-specific KDF-based A128CBC_HS256 and
A256CBC_HS512 JWAs, but in a spec of its own and in a way that is more
broadly applicable. 

The spirit of the IETF standards is to provide a body of useful and
interconnected specs that refer to one another, instead of reinventing
the wheel each time. This makes the individual specs simpler and more
focused, and helps with software reuse and interoperability. I suggest
we follow this good spirit and adopt McGrew's draft.

If the draft needs to be amended to suit some particular JOSE encoding
requirement, the authors would be glad to cooperate with us, as they
have written in section 4 Rationale.

What do we gain by adopting McGrew's draft:

* We can have a common spec for authenticated AES/CBC with W3C web
crypto to refer to.

* We gain the expertise and the support of the McGrew draft authors.

* The McGrew draft has better chances to become a mainstream solution
for authenticated AES/CBC, with following library implementations, and
even more so if we adopt it (than our JOSE KDF alg).

* The JOSE specs remain focused on what they were initially intended to
achieve - specify a nimble JSON format for crypto messages, not delving
into devising new crypto algorithms :)


Yes, we will lose the work that was already done to implement the
KDF-based AES/CBC AEAD. I have also spent time on that. But the end
result will be better for us and the community, I believe.


Thanks,

Vladimir

--
Vladimir Dzhuvinov : www.NimbusDS.com : [e-mail]


-------- Original Message --------
Subject: Re: [jose] Use of AES-HMAC algorithm
From: "Manger, James H" <[e-mail]>
Date: Thu, March 28, 2013 4:40 am
To: Dick Hardt <[e-mail]>
Cc: "[e-mail]" <[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
> >

_______________________________________________
jose mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/jose