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.4 > and > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5 > to 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.java >> and 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.4 >> and >> 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 >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
