Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

[Richard Barnes <[e-mail]>]

On JS binary: The future is now, in most major browsers.
<http://www.khronos.org/registry/typedarray/specs/latest/>

-----BEGIN-----
var x = new Uint8Array([1,2,3,4]);
var y = new Uint8Array([5,6,7,8]);
// Concatenate
var z = new Uint8Array( x.byteLength + y.byteLength );
z.set(x, 0);
z.set(y, x.byteLength);
// z == [1,2,3,4,5,6,7,8]
-----END-----

For example: GCM implementation in javascript:
<http://polycrypt.net/back/lib/gcm.js>


On Tue, Mar 12, 2013 at 8:58 PM, Manger, James H <
[e-mail]> wrote:

> +1 for using the McGrew draft and RFC 5116 interface.****
>
> ** **
>
> The JOSE-specific A128CBC+HS256 algorithm looks like a valiant attempt to
> hide some of the binary processing involved with crypto – which has always
> been defined on bytes, not text. But the result is a poor chimera.****
>
> ** **
>
> For instance, JWE includes the IV as part of the additional authenticated
> data (AAD). No other AEAD system is defined like this. Everywhere else the
> IV/nonce and AAD are separate. I hope that doesn’t adversely affect the
> crypto properties, but it does raise questions about whether it is
> important for some crypto reason.****
>
> ** **
>
> Every AEAD algorithm treats the AAD and ciphertext as bytes arrays with no
> restrictions on their content (only restrictions on their length). Hence
> they use some binary packing when processing both to calculate an integrity
> check. EXCEPT the JOSE-specific AEAD algorithms (A128CBC+HS256 and
> A256CBC+HS512). They force base64url-encoding **inside** the AEAD
> algorithm so they can use a text dot “.” as a separator.****
>
> ** **
>
> While A128CBC+HS256 is implemented by hand in JOSE-specific code using AES
> and HMAC primitives the problems with this chimera are mainly hidden.
> However, I don’t believe any generic AEAD interface can ever handle this
> JOSE-specific algorithm efficiently.****
>
> ** **
>
> The “extra work” of adopting the AEAD encoding/decoding conventions is:
> concatenating byte arrays; and taking a known-length prefix and suffix from
> a byte array. You cannot get much simpler. It can only be an annoyance for
> a language that is not byte-array-friendly, but even such a language will
> have to handle byte arrays at some point to interface with crypto.****
>
> ** **
>
> Even using the McGrew draft then separating the output into
> IV/ciphertext/MAC to re-package as a JOSE message would be better than the
> JOSE-specific A128CBC+HS256 and A256CBC+HS512.****
>
> ** **
>
> P.S. I think ECMAScript edition 6 is introducing support for byte arrays
> so even hassle handling bytes in JavaScript should fade.****
>
> ** **
>
> --****
>
> James Manger****
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Mike Jones
> *Sent:* Wednesday, 13 March 2013 8:06 AM
> *To:* Peck, Michael A; John Bradley
> *Cc:* Richard Barnes; [e-mail]
>
> *Subject:* Re: [jose] Concat KDF issues with ECDH-ES and for deriving
> CEK/CIK from CMK****
>
> ** **
>
> Possibly using the McGrew draft had been discussed before, but there was
> strong push-back on it.  It would change more than the CBC/HMAC
> representation – it would change all the JWE representations, as it would
> remove the Initialization Vector and Integrity Value fields, and instead
> require all implementations to implement and apply the AEAD binary encoding
> and decoding conventions.  Note that this would change AES-GCM too – not
> just AES-CBC/HMAC.****
>
> ** **
>
> If commonly available crypto libraries implemented algorithms using the
> AEAD encoding conventions I would have no problem with this.  But in fact,
> they don’t.  I don’t know of a single library in the attached set of
> surveyed implementations that do.  Thus, adopting the AEAD
> encoding/decoding conventions would create extra work for all
> implementations in practice – not make things simpler.  It would only be
> simpler if the existing crypto libraries implemented this standard
> interface.****
>
> ** **
>
> We should therefore steer clear of this.****
>
> ** **
>
>                                                             Best wishes,**
> **
>
>                                                             -- Mike****
>
> ** **
>
> P.S.  Jim Schaad also points out that CMS doesn’t use the RFC 5116
> interface either.****
>
> ** **
>
> *From:* Peck, Michael A [mailto:[e-mail] <[e-mail]>]
> *Sent:* Tuesday, March 12, 2013 2:02 PM
> *To:* John Bradley; Mike Jones
> *Cc:* Richard Barnes; [e-mail]
> *Subject:* RE: [jose] Concat KDF issues with ECDH-ES and for deriving
> CEK/CIK from CMK****
>
> ** **
>
> I think that #2 actually reduces complexity for implementers.****
>
> They can implement the RFC 5116 interface once (or eventually just invoke
> a crypto library that implements it for them) – then use that
> implementation for all protocols that use the RFC 5116 interface, not just
> JOSE, and know that the details of authenticated encryption have been taken
> care of. ****
>
> ** **
>
> Mike****
>
> ** **
>
> ** **
>
> *From:* John Bradley [mailto:[e-mail] <[e-mail]>]
> *Sent:* Tuesday, March 12, 2013 4:49 PM
> *To:* Mike Jones
> *Cc:* Richard Barnes; Peck, Michael A; [e-mail]
> *Subject:* Re: [jose] Concat KDF issues with ECDH-ES and for deriving
> CEK/CIK from CMK****
>
> ** **
>
> Yes I have the recommendation to change from using a KDF to generate the
> CEK and CIK from the CMK to concatenating the CEK and CIK together as in
> the McGrew draft.****
>
> ** **
>
> I don't yet have a slide on the new/old issue of concatenating the tag to
> the message body vs sending it in a separate field.   ****
>
> ** **
>
> If people want me to I can add it as well.  Though I thought that was a
> closed issue.  ****
>
> ** **
>
> John B.****
>
> ** **
>
> On 2013-03-12, at 4:19 PM, Mike Jones <[e-mail]> wrote:
> ****
>
> ** **
>
> As previously extensively discussed, the McGrew draft does two things –
> one helpful and one not:****
>
>  ****
>
> 1.  It specifies using a key that is actually the concatenation of an
> AES-CBC key and an HMAC SHA-2 key, rather than use of a KDF.  That’s good,
> as it’s simple for implementers.****
>
>  ****
>
> 2.  It specifies that the initialization vector and integrity value be
> concatenated with other values in particular ways, and conversely, how to
> extract them when decrypting.  That’s not good, as it adds complexity for
> implementers – especially when JWEs already utilize a straightforward
> representation for these values, which doesn’t require the binary
> concatenation and extraction conventions specified by McGrew.****
>
>  ****
>
> I know that John Bradley is going to ask the question tomorrow whether we
> should change to doing the first for our composite CBC+HMAC algorithms.  I
> believe that doing the second would be counterproductive.****
>
>  ****
>
>                                                             -- Mike****
>
>  ****
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf Of
>  *Richard Barnes
> *Sent:* Tuesday, March 12, 2013 1:00 PM
> *To:* Peck, Michael A
> *Cc:* [e-mail]
> *Subject:* Re: [jose] Concat KDF issues with ECDH-ES and for deriving
> CEK/CIK from CMK****
>
>  ****
>
> Actually, for everything but key agreement, we can just
> use draft-mcgrew-aead-aes-cbc-hmac-sha2, with larger keys.  We should not
> be specifying key expansion here when we can avoid it.****
>
>  ****
>
> --Richard****
>
>  ****
>
>  ****
>
> On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A <[e-mail]> wrote:*
> ***
>
> draft-ietf-jose-json-web-algorithms-08 section 4.7.1 describes the use of
> Concat KDF on the shared secret Z established by ECDH-ES.****
>
>  ****
>
> The draft allows for an empty PartyUInfo and PartyVInfo but that may not
> be allowed by NIST SP 800-56A (where the Concat KDF is defined).****
>
> The current (March 2007) version of NIST SP 800-56A requires “At a
> minimum, *PartyUInfo **shall *include *ID**U*, the identifier of party *U*.”
> and an equivalent requirement for PartyVInfo. (Page 46 of
> http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf
>  )****
>
> The August 2012 draft update to NIST SP 800-56A requires “At a minimum,
> PartyUInfo shall include IDu, an identifier for party U, as a distinct item
> of information.” and an equivalent requirement for PartyVInfo. (Page 59 of
>  http://csrc.nist.gov/publications/drafts/800-56a/draft-sp-800-56a.pdf )
> My interpretation of this text (others may interpret it differently) is
> that PartyUInfo and PartyVInfo can’t be empty.****
>
>  ****
>
> Instead of using the Concat KDF, a more appropriate choice may be the KDF
> described in NIST SP 800-56C and RFC 5869.****
>
> Its requirements are not as strict.  (SP 800-56C Page 13: “If the
> information is available, *Context **should *include the identifiers of
> the parties who are deriving and/or using the derived keying material”)***
> *
>
>  ****
>
> It would look something like this:****
>
>  ****
>
> Step 1 - Randomness Extraction:****
>
> Key Derivation Key := HMAC(salt, Z)         (HMAC-SHA256 should suffice
> for all of the current algorithms)****
>
>  ****
>
> Step 2 - Expansion Step:****
>
> Use the Counter Mode KDF defined in SP 800-108 or section 2.3 of RFC 5869
> with the same HMAC algorithm used in step 1 to produce needed keys from the
> Key Derivation Key produced in step 1.****
>
> The needed keys would depend on the values of alg and enc.****
>
> If alg is ECDH-ES+A128KW or ECDH-ES+A256KW, a single 128 bit or 256 bit
> key is needed (used to decrypt the CMK, which may then need to be split
> into CEK/CIK).****
>
> If alg is ECDH-ES, then the needed keys depend on “enc”:****
>
> If enc is AES-GCM, a 128 bit key or 256 bit key is needed.****
>
> If enc is one of the AEAD AES-CBC algorithms in
> draft-mcgrew-aead-aes-cbc-hmac-sha2-01, a key of ENC_KEY_LEN + MAC_KEY_LEN
> is needed as it’s then split into two by the AEAD algorithm.****
>
> If enc is one of the current CBC+HMAC options in
> draft-ietf-jose-json-web-algorithms-08, then two keys are needed, a CEK and
> a CIK.  Counter Mode KDF could be invoked twice, with different labels each
> time, or Counter Mode KDF could be invoked once to generate a big key which
> would then be split into the CEK and CIK.****
>
>  ****
>
> Richard has already pointed out the issues with using the Concat KDF to
> derive the CEK/CIK from the CMK.  Instead, one option would be to use the
> Expansion Step above:  use the Counter Mode KDF with an HMAC to derive
> necessary keys from the CMK. ****
>
> Even if we use encryption algorithms that combine the encryption and
> integrity key such as the CBC+HMAC algorithms in
> draft-mcgrew-aead-aes-cbc-hmac-sha2-01, there will still be a need to take
> a smaller master key and create the combined encryption + integrity key
> from it.****
>
>  ****
>
>  ****
>
> Mike****
>
>  ****
>
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose****
>
>  ****
>
> _______________________________________________
> jose mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>