- From: Ryan Sleevi <sleevi@google.com>
- Date: Mon, 29 Oct 2012 16:23:30 -0700
- To: Axel.Nennker@telekom.de
- Cc: Michael.Jones@microsoft.com, jose@ietf.org, public-webcrypto@w3.org
- Message-ID: <CACvaWvZaBgsBsMMLY0CXr4nAPgYkC9GqJr1Y5y9gQH_d4OWcJA@mail.gmail.com>
On Mon, Oct 29, 2012 at 1:46 PM, <Axel.Nennker@telekom.de> 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.**** > > ” > 1) That's not the digest interface, that's the HMAC interface 2) That's not part of NSS - that's some Mozilla binding for Firefox, and, AIUI, not one meant to be exposed to extentions intentionally (only accidentally) 3) NSS supports cloning digests to maintain their internal state - see http://mxr.mozilla.org/security/source/security/nss/lib/cryptohi/sechash.hand HASH_HashClone 4) If concat-KDF is supported via NSS, it would not be exposed via the API you referenced anyways 5) I agree with Mike that implementing concat-KDF using a Hash (NOT an HMAC function) is a fairly trivial thing to do and is similar to other KDFs > **** > > 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. > NSS's KDFs are those specified in PKCS#11. Concat-KDF is newer than the newest draft PKCS#11 spec (v2.3 draft 7), hence, no PKCS#11 identifier exists yet for Concat-KDF, hence, NSS has not yet implemented it. The current stable PKCS#11 release (v2.2) was published 8 years ago, and you can see all the KDFs even mentioned at http://www.cryptsoft.com/pkcs11doc/STANDARD/pkcs-11v2-20.pdf There's nothing preventing NSS from implementing it in the vendor-specific mechanism range, and presumably would do so if needed by NSS-using applications (such as Firefox or Chrome). However, as an NSS developer, I do not see your presented argument as a reason not to use Concat-KDF, and Concat-KDF would be more preferable, as a NIST-blessed KDF, since NSS cares especially for NIST-blessed algorithms. > ** > > ** ** > > 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 > Because NIST and KDFs have a long and sordid history, generally frowning on most, and then later only discussing constructions (that is, entire classes of KDFs) rather than specific KDFs. > **** > > ** ** > > 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. > I disagree, as someone who has had to deal with NIST, works on NSS, and, through working on Chromium, is very much invested and interested in cross-platform crypto issues. > **** > > ** ** > > 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:Michael.Jones@microsoft.com] > *Sent:* Monday, October 29, 2012 5:25 PM > *To:* Nennker, Axel; jose@ietf.org > > *Cc:* public-webcrypto@w3.org > *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:* Axel.Nennker@telekom.de [mailto:Axel.Nennker@telekom.de] > *Sent:* Monday, October 29, 2012 6:03 AM > *To:* Mike Jones; jose@ietf.org > *Cc:* public-webcrypto@w3.org > *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:* jose-bounces@ietf.org [mailto:jose-bounces@ietf.org<jose-bounces@ietf.org>] > *On Behalf Of *Mike Jones > *Sent:* Monday, October 29, 2012 7:28 AM > *To:* jose@ietf.org > *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**** > > ** ** >
Received on Monday, 29 October 2012 23:23:53 UTC