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
