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) <[email protected]> > > On Oct 29, 2012, at 4:24 PM, Mike Jones <[email protected]> > 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 < [email protected] > > Cisco Systems, Inc. > > -- Mike > > > > -----Original Message----- > > From: Matt Miller (mamille2) [mailto:[email protected]] > > Sent: Monday, October 29, 2012 3:16 PM > > To: <[email protected]> > > Cc: Mike Jones; <[email protected]>; <[email protected]> > > Subject: Re: [jose] Platform Support for JWA Crypto Algorithms > > > > > > On Oct 29, 2012, at 2:46 PM, <[email protected]> > > 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 < [email protected] > > > 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:[email protected]] > >> Sent: Monday, October 29, 2012 5:25 PM > >> To: Nennker, Axel; [email protected] > >> Cc: [email protected] > >> 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: [email protected] [mailto:[email protected]] > >> Sent: Monday, October 29, 2012 6:03 AM > >> To: Mike Jones; [email protected] > >> Cc: [email protected] > >> 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: [email protected]<mailto:[email protected]> [mailto: > [email protected]] On Behalf Of Mike Jones > >> Sent: Monday, October 29, 2012 7:28 AM > >> To: [email protected]<mailto:[email protected]> > >> 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 > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/jose > > > > > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
