Re: Platform Support for JWA Crypto Algorithms

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****
>
> ** **
>