Re: [jose] Platform Support for JWA Crypto Algorithms

[Axel Nennker <[e-mail]>]

I think that https://tools.ietf.org/html/rfc2898 (
https://en.wikipedia.org/wiki/PBKDF2) is a better choice than the
concat-kdf from NIST.
PBKDF2 does not care whether the password consists of printable characters
or whether it is a randomly generated byte strink like our CMK.
There is no need to base64url the key/cmk.

In the wikipedia article is a list of implementations which sounds much
better than our current rows in our crypto-algs compat-table.

I suggest we use PBKDF2(HMACSHA1, cmk, iv||"Integrity", 1000) to generate
cik and PBKDF2(SHA256, cmk, iv||"Encryption", 1000) to generate the cek.
"||" is concatenation. HMACSHA1 as default (MTI) and HMACSHA256 as
recommended?!

Or we could use my earlier proposal to define the first interation of the
concat-kdf as the default for our currently defined encryption algorithms.
  CIK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 49, 57, 50, 67, 66, 67, 43,
72, 83, 50, 53, 54, 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255]
  CEK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 43,
72, 83, 50, 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-255]
or something along those lines...

Axel

2012/10/30 Matt Miller (mamille2) <[e-mail]>

>
> On Oct 29, 2012, at 4:24 PM, Mike Jones <[e-mail]>
> wrote:
>
> > The "PB" in PBKDF2 is "Password Based".  This and related KDFs generate
> keys from passwords rather than other keys, and so are not applicable for
> this use case.
> >
>
> Maybe this is too hacky for people, but: PBKDF2(H, base64url(key), salt,
> iters)
>
> > For lack of a commonly implemented key-based KDF, we chose a very simple
> one that only requires support for SHA-256 and SHA-512 to build for our use
> cases.  (Heck, for our use cases, implementations don't even require a loop
> - just a single hash calculation over the input.)  I already know of 5
> interoperable implementations at this point.  It's just not that hard.
> >
> > See the example calculations in
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4and
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5to see how simple it actually is.
> >
>
> If we're going for least difficulty, then why not just use key that's
> (cipher-len + hash-len) in the first place?
>
>
> - m&m
>
> Matt Miller < [e-mail] >
> Cisco Systems, Inc.
> >                               -- Mike
> >
> > -----Original Message-----
> > From: Matt Miller (mamille2) [mailto:[e-mail]]
> > Sent: Monday, October 29, 2012 3:16 PM
> > To: <[e-mail]>
> > Cc: Mike Jones; <[e-mail]>; <[e-mail]>
> > Subject: Re: [jose] Platform Support for JWA Crypto Algorithms
> >
> >
> > On Oct 29, 2012, at 2:46 PM, <[e-mail]>
> > wrote:
> >
> >> Ease of implementation is relative. Maybe tomorrow I will discover that
> the needed concat-KDF is supported "natively" by Mozilla's NSS library.
> Then it is very easy.
> >> Currently it looks difficult on that platform because the documentation
> says that the digest function "finish" resets the digest, which would
> probably lead to different results than in the examples in the appendices
> A4 and A5.
> >> "
> http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d1ac9e69aafc30f71ba35da74e
> >> NOTE: This method may be called any time after |init| is called. This
> call resets the object to its pre-init state.
> >> "
> >> I still think that some thirty bytes is not much and that generating
> the CIK randomly is much easier. I implemented the concat-kdf in java
> >>
> https://code.google.com/p/jsoncrypto/source/browse/trunk/src/org/jsoncrypto/crypto/KDFConcatGenerator.javaand I know that implementing my proposal below is easier.
> >> Anyway: One could ask why the concat-KDF is not implemented in
> Bouncycastle while three other KDFs are implemented there.
> >> Mozilla implements KDFs too:
> >>
> https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11skey.c#1437
> >> Although there is no indication in the code which KDF this implements.
> Maybe a Mozillian on these lists can clarify.
> >> If it is a KDF that is implemented in Bouncycastle too then I suggest
> to change the default KDF in JWE to that one.
> >>
> >> The implementation of KDF can lead to buffer overflows is no secret:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=617565
> >> Which means that KeyDerivationFunction implementation is not as easy as
> it could be.
> >>
> >> Why do you think that the list of NIST's crypto implementations lists
> all algs except KDF?
> >>
> http://csrc.nist.gov/groups/STM/cavp/documents/components/componentval.html
> >>
> >> NIST defines other KDFs too. Why is JWE using one that is implemented
> nowhere? Any other choice that is implemented on two platforms is a better
> choice than concat-kdf I think.
> >>
> >
> > To add more fuel to the fire: I've seen PBKDF2 is implemented in a few
> places, and I think it's only slightly harder to implement as concatKDF.
> >
> > However, I still think just requiring a larger key is the easiest, least
> error-prone approach.
> >
> >
> > - m&m
> >
> > Matt Miller < [e-mail] >
> > Cisco Systems, Inc.
> >
> >> Axel
> >>
> >>
> http://doxygen.db48x.net/mozilla/html/interfacensICryptoHMAC.html#afa7330d1ac9e69aafc30f71ba35da74e
> >> NOTE: This method may be called any time after |init| is called. This
> call resets the object to its pre-init state.
> >>
> >> From: Mike Jones [mailto:[e-mail]]
> >> Sent: Monday, October 29, 2012 5:25 PM
> >> To: Nennker, Axel; [e-mail]
> >> Cc: [e-mail]
> >> Subject: RE: Platform Support for JWA Crypto Algorithms
> >>
> >> No, Concat often isn't natively supported, but it's very easy to
> implement given implementations of SHA-256 and SHA-512, as shown in
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.4and
> http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5
> .
> >>
> >> When the table was discussed at the WebCrypto F2F, it was pointed out
> that a shortcoming of the current table is that it doesn't indicate which
> of the "NO" values are effectively show-stoppers and which are easy to
> build implementations of, and so not a problem in practice.  As shown in
> the appendices, I believe that Concat is in the latter category.  Given the
> ease of implementation, it's certainly not worth adding space to the JWEs
> to work around.
> >>
> >>                                                           -- Mike
> >>
> >> From: [e-mail] [mailto:[e-mail]]
> >> Sent: Monday, October 29, 2012 6:03 AM
> >> To: Mike Jones; [e-mail]
> >> Cc: [e-mail]
> >> Subject: RE: Platform Support for JWA Crypto Algorithms
> >>
> >> As one can see from this table the KDF is unsupported on all platforms
> (except one).
> >>
> http://self-issued.info/presentations/Platform_Support_for_JWA-04_Crypto_Algorithms.xlsx
> >>
> >> JWE
> >>
> >> kdf
> >>
> >> CS256
> >>
> >> Concat Key Derivation Function (KDF)
> >>
> >> NO
> >>
> >> Win7
> >>
> >>
> >>
> >>
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >>
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> JWE
> >>
> >> kdf
> >>
> >> CS384
> >>
> >> Concat Key Derivation Function (KDF)
> >>
> >> NO
> >>
> >> Win7
> >>
> >>
> >>
> >>
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >>
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> JWE
> >>
> >> kdf
> >>
> >> CS512
> >>
> >> Concat Key Derivation Function (KDF)
> >>
> >> NO
> >>
> >> Win7
> >>
> >>
> >>
> >>
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >>
> >>
> >> NO
> >>
> >> NO
> >>
> >> NO
> >>
> >>
> >> Isn't this an indication that we should look at alternatives?
> >>
> >> e.g.: we could generate the integrity protection key randomly instead
> of deriving it from the content encryption key.
> >> This would add some more bytes (e.g. about 32) to the jwt but is very
> easy to implement on all platforms.
> >>
> >>
> >> One way to do it would be to generate enough bytes "Bytes" in "JWE
> Encrypted Key" for encryption and integrity.
> >> The CEK is then "Bytes[0 .. cekLength-1]" and the CIK "Bytes[cekLength
> .. cekLength+cikLength-1]"
> >>
> >>
> >> Axel
> >>
> >> [On some platforms (Firefox/NSS) it might even be nearly impossible to
> implement (without extending the platform's functions) because the build-in
> digest function is always reset when finalize (doFinal) is called. The spec
> of the Concat-KDF says that bytes are generated in a loop but the digest is
> NOT reset in the loop.]
> >>
> >>
> >> From: [e-mail]<mailto:[e-mail]> [mailto:
> [e-mail]] On Behalf Of Mike Jones
> >> Sent: Monday, October 29, 2012 7:28 AM
> >> To: [e-mail]<mailto:[e-mail]>
> >> Subject: [jose] Platform Support for JWA Crypto Algorithms
> >>
> >> FYI, I posted the table describing support for the JWA algorithms in
> common Web development platforms that we discussed at IETF 84.  See
> http://self-issued.info/?p=884.
> >>
> >>                                                           -- 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
>
>