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

From: "Peck, Michael A" <[email-masked]>
Date: Tue, 12 Mar 2013 18:29:18 +0000

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 IDU, 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

---

From: Richard Barnes <[email-masked]>
Date: Tue, 12 Mar 2013 15:59:42 -0400

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 <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jose
>
>

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Mar 2013 20:19:59 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 1:00 PM
To: Peck, Michael A
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> 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.

Step 2 - Expansion Step:

Mike

_______________________________________________
jose mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/jose

---

From: John Bradley <[email-masked]>
Date: Tue, 12 Mar 2013 16:48:31 -0400

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 <[email-masked]> 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.
>  
> The current (March 2007) version of NIST SP 800-56A requires “At a minimum, PartyUInfo shall include IDU, the identifier of party U.” and an equivalent requirement for PartyVInfo. (Page 46 ofhttp://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.
>  
> 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”)
> 
>  
> If alg is ECDH-ES, then the needed keys depend on “enc”:
> 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.

---

From: "Peck, Michael A" <[email-masked]>
Date: Tue, 12 Mar 2013 21:01:41 +0000

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:[email-masked]]
Sent: Tuesday, March 12, 2013 4:49 PM
To: Mike Jones
Cc: Richard Barnes; Peck, Michael A; [email-masked]
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

John B.

On 2013-03-12, at 4:19 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:

                                                            -- Mike

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Richard Barnes
Sent: Tuesday, March 12, 2013 1:00 PM
To: Peck, Michael A
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

--Richard

The current (March 2007) version of NIST SP 800-56A requires "At a minimum, PartyUInfo shall include IDU, the identifier of party U." and an equivalent requirement for PartyVInfo. (Page 46 ofhttp://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf )

Step 2 - Expansion Step:

Mike

---

From: Mike Jones <[email-masked]>
Date: Tue, 12 Mar 2013 21:06:24 +0000

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:[email-masked]]
Sent: Tuesday, March 12, 2013 2:02 PM
To: John Bradley; Mike Jones
Cc: Richard Barnes; [email-masked]
Subject: RE: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

Mike

From: John Bradley [mailto:[email-masked]]
Sent: Tuesday, March 12, 2013 4:49 PM
To: Mike Jones
Cc: Richard Barnes; Peck, Michael A; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

John B.

                                                            -- Mike

--Richard

Step 2 - Expansion Step:

Mike

---

From: "Manger, James H" <[email-masked]>
Date: Wed, 13 Mar 2013 11:58:49 +1100

+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: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Wednesday, 13 March 2013 8:06 AM
To: Peck, Michael A; John Bradley
Cc: Richard Barnes; [email-masked]
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.

                                                            Best wishes,
                                                            -- Mike

P.S.  Jim Schaad also points out that CMS doesn’t use the RFC 5116 interface either.

Cc: Richard Barnes; [email-masked]<mailto:[email-masked]>

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

John B.

                                                            -- Mike

--Richard

Step 2 - Expansion Step:

Mike

---

From: Richard Barnes <[email-masked]>
Date: Thu, 14 Mar 2013 13:48:05 -0400

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 <
[email-masked]> 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:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *Mike Jones
> *Sent:* Wednesday, 13 March 2013 8:06 AM
> *To:* Peck, Michael A; John Bradley
> *Cc:* Richard Barnes; [email-masked]
>
> *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:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, March 12, 2013 2:02 PM
> *To:* John Bradley; Mike Jones
> *Cc:* Richard Barnes; [email-masked]
> *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:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, March 12, 2013 4:49 PM
> *To:* Mike Jones
> *Cc:* Richard Barnes; Peck, Michael A; [email-masked]
> *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.****
>
> ** **
>
> 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:* [email-masked] [mailto:[email-masked]] *On Behalf Of
>  *Richard Barnes
> *Sent:* Tuesday, March 12, 2013 1:00 PM
> *To:* Peck, Michael A
> *Cc:* [email-masked]
> *Subject:* Re: [jose] Concat KDF issues with ECDH-ES and for deriving
> CEK/CIK from CMK****
>
>  ****
>
> be specifying key expansion here when we can avoid it.****
>
>  ****
>
> --Richard****
>
>  ****
>
>  ****
>
> On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A <[email-masked]> 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.****
>
>  ****
>
> http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf
>  )****
>
> the parties who are deriving and/or using the derived keying material”)***
> *
>
>  ****
>
> Step 2 - Expansion Step:****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/jose****
>
> ** **
>

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 15 Mar 2013 14:09:34 -0400

From: [email-masked] [mailto:[email-masked]] On Behalf Of Manger, James H
Sent: Tuesday, March 12, 2013 8:59 PM
To: Mike Jones; Peck, Michael A; John Bradley
Cc: Richard Barnes; [email-masked]
Subject: Re: [jose] Concat KDF issues with ECDH-ES and for deriving CEK/CIK from CMK

[JLS] For this algorithm it is absolutely vital that the IV be protected.  Since the authentication is computed on the post encrypted text not the pre-encyrpted text, a decryption could never be able to correctly determine that the IV passed in was correct if it is not validated!!!!!!

--

James Manger

                                                            Best wishes,

                                                            -- Mike

Mike

John B.

                                                            -- Mike

--Richard

On Tue, Mar 12, 2013 at 2:29 PM, Peck, Michael A < <mailto:[email-masked]> [email-masked]> wrote:

The current (March 2007) version of NIST SP 800-56A requires “At a minimum, PartyUInfo shall include IDU, 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> 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> 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.

Step 2 - Expansion Step:

 

Mike

_______________________________________________
jose mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/jose> https://www.ietf.org/mailman/listinfo/jose

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 18 Mar 2013 11:02:25 +1100

Jim,

A256CBC+HS512 needs to integrity-protect the IV. I am not disagreeing with that.

Every other AEAD algorithm accepts an IV and AAD as separate inputs and *internally to the AEAD algorithm* ensures the appropriate integrity protection is applied. This is what GCM, CCM, and SIV do. It is the what RFC5116 (AEAD interface) assumes. It is what any crypto library with an explicit AEAD interface will support (separate calls or separate parameters for the IV and AAD).

JWE defines the AAD to be the Header+WrappedKey+IV. That is, the IV is included in the AAD.

Consequently every other AEAD algorithm (such as A128GCM) will process the JWE IV twice. In A128GCM, for example, the IV will be passed from JOSE code to an underlying crypto API once as a 12-byte (96-bit) binary value, and also as 16 base64url characters at the end of the AAD. For all these AEAD algorithms this duplication is merely slightly wasteful, but I guess (hope) it has no impact on security.

The JOSE-specific A256CBC+HS512 algorithm, in contrast, is different. This algorithm would be insecure if the AAD did not include the IV. What would happen if A256CBC+HS512 was implemented in a crypto library accessed via a generic AEAD interface? Perhaps it would have to base64url-encode the IV it was passed and check that it matches the end of the AAD it was passed (making it unsuitable as a generic AEAD alg in any other context)?

--
James Manger

---

From: Richard Barnes <[email-masked]>
Date: Mon, 18 Mar 2013 11:42:10 -0400

This sounds to me like yet another argument for (1) removing the integrity
protection from the JOSE header, and (2) creating a separate binary
component in JWE to hold the AAD.

--Richard

On Sun, Mar 17, 2013 at 8:02 PM, Manger, James H <
[email-masked]> wrote:

> >> 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.****
>
> ** **
>
> [JLS] For this algorithm it is absolutely vital that the IV be protected.
> Since the authentication is computed on the post encrypted text not the
> pre-encyrpted text, a decryption could never be able to correctly determine
> that the IV passed in was correct if it is not validated!!!!!!****
>
> ** **
>
> ** **
>
> Jim,****
>
> ** **
>
> A256CBC+HS512 needs to integrity-protect the IV. I am not disagreeing with
> that.****
>
> ** **
>
> Every other AEAD algorithm accepts an IV and AAD as separate inputs and **internally
> to the AEAD algorithm** ensures the appropriate integrity protection is
> applied. This is what GCM, CCM, and SIV do. It is the what RFC5116 (AEAD
> interface) assumes. It is what any crypto library with an explicit AEAD
> interface will support (separate calls or separate parameters for the IV
> and AAD).****
>
> ** **
>
> JWE defines the AAD to be the Header+WrappedKey+IV. That is, the IV is
> included in the AAD.****
>
> ** **
>
> Consequently every other AEAD algorithm (such as A128GCM) will process the
> JWE IV twice. In A128GCM, for example, the IV will be passed from JOSE code
> to an underlying crypto API once as a 12-byte (96-bit) binary value, and
> also as 16 base64url characters at the end of the AAD. For all these AEAD
> algorithms this duplication is merely slightly wasteful, but I guess (hope)
> it has no impact on security.****
>
> ** **
>
> The JOSE-specific A256CBC+HS512 algorithm, in contrast, is different. This
> algorithm would be insecure if the AAD did not include the IV. What would
> happen if A256CBC+HS512 was implemented in a crypto library accessed via a
> generic AEAD interface? Perhaps it would have to base64url-encode the IV it
> was passed and check that it matches the end of the AAD it was passed
> (making it unsuitable as a generic AEAD alg in any other context)?****
>
> ** **
>
> --****
>
> James Manger****
>