Re: [jose] Platform Support for JWA Crypto Algorithms
Mike Jones <Michael.Jones@microsoft.com> Mon, 29 October 2012 22:24 UTC
Return-Path: <Michael.Jones@microsoft.com>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9799121F8647 for <jose@ietfa.amsl.com>; Mon, 29 Oct 2012 15:24:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5UmvLad8PuDu for <jose@ietfa.amsl.com>; Mon, 29 Oct 2012 15:24:49 -0700 (PDT)
Received: from NA01-BL2-obe.outbound.protection.outlook.com (na01-bl2-obe.ptr.protection.outlook.com [65.55.169.32]) by ietfa.amsl.com (Postfix) with ESMTP id 307AF21F8646 for <jose@ietf.org>; Mon, 29 Oct 2012 15:24:48 -0700 (PDT)
Received: from BY2FFO11FD001.protection.gbl (10.1.15.200) by BY2FFO11HUB009.protection.gbl (10.1.14.167) with Microsoft SMTP Server (TLS) id 15.0.545.8; Mon, 29 Oct 2012 22:24:39 +0000
Received: from TK5EX14MLTC102.redmond.corp.microsoft.com (131.107.125.37) by BY2FFO11FD001.mail.protection.outlook.com (10.1.14.123) with Microsoft SMTP Server (TLS) id 15.0.545.8 via Frontend Transport; Mon, 29 Oct 2012 22:24:39 +0000
Received: from TK5EX14MBXC285.redmond.corp.microsoft.com ([169.254.3.15]) by TK5EX14MLTC102.redmond.corp.microsoft.com ([157.54.79.180]) with mapi id 14.02.0318.003; Mon, 29 Oct 2012 22:24:26 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>, "<Axel.Nennker@telekom.de> " <Axel.Nennker@telekom.de>
Thread-Topic: [jose] Platform Support for JWA Crypto Algorithms
Thread-Index: Ac21npPqwtcuERVxRaibRdRS35KObwANGVoQAAd5tsAACDLiIAAO0JKAAApuFWA=
Date: Mon, 29 Oct 2012 22:24:25 +0000
Message-ID: <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com>
References: <4E1F6AAD24975D4BA5B168042967394366880D09@TK5EX14MBXC285.redmond.corp.microsoft.com> <CE8995AB5D178F44A2154F5C9A97CAF40252198DCF55@HE111541.emea1.cds.t-internal.com> <4E1F6AAD24975D4BA5B16804296739436688123A@TK5EX14MBXC285.redmond.corp.microsoft.com> <CE8995AB5D178F44A2154F5C9A97CAF40252199B9114@HE111541.emea1.cds.t-internal.com> <BF7E36B9C495A6468E8EC573603ED94115076832@xmb-aln-x11.cisco.com>
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED94115076832@xmb-aln-x11.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.71]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(24454001)(69234002)(377454001)(51704002)(13464001)(54316001)(48376001)(8716001)(47736001)(3846001)(20776001)(47976001)(46102001)(16826001)(51856001)(54356001)(5343665001)(15202345001)(551544001)(47776002)(4196001)(47446002)(74502001)(44976002)(53806001)(16406001)(1076001)(4396001)(50466001)(74662001)(50986001)(16696001)(5343645001)(33656001)(31966008)(5343635001)(5343655001)(49866001)(6606295001)(3556001)(3746001); DIR:OUT; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 064903DDDC
Cc: "<public-webcrypto@w3.org>" <public-webcrypto@w3.org>, "<jose@ietf.org>" <jose@ietf.org>
Subject: Re: [jose] Platform Support for JWA Crypto Algorithms
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Oct 2012 22:24:50 -0000
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. 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. -- Mike -----Original Message----- From: Matt Miller (mamille2) [mailto:mamille2@cisco.com] Sent: Monday, October 29, 2012 3:16 PM To: <Axel.Nennker@telekom.de> Cc: Mike Jones; <jose@ietf.org>; <public-webcrypto@w3.org> Subject: Re: [jose] Platform Support for JWA Crypto Algorithms On Oct 29, 2012, at 2: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. > " > 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 < mamille2@cisco.com > 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: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.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: 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> [mailto:jose-bounces@ietf.org] On Behalf Of Mike Jones > Sent: Monday, October 29, 2012 7:28 AM > To: jose@ietf.org<mailto: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 > > _______________________________________________ > jose mailing list > jose@ietf.org > https://www.ietf.org/mailman/listinfo/jose
- [jose] Platform Support for JWA Crypto Algorithms Mike Jones
- Re: [jose] Platform Support for JWA Crypto Algori… Axel.Nennker
- Re: [jose] Platform Support for JWA Crypto Algori… Mike Jones
- Re: [jose] Platform Support for JWA Crypto Algori… Axel.Nennker
- Re: [jose] Platform Support for JWA Crypto Algori… Matt Miller (mamille2)
- Re: [jose] Platform Support for JWA Crypto Algori… Mike Jones
- Re: [jose] Platform Support for JWA Crypto Algori… Axel Nennker
- [jose] NIST Concat KDF Manger, James H
- Re: [jose] Platform Support for JWA Crypto Algori… Matt Miller (mamille2)
- Re: [jose] Platform Support for JWA Crypto Algori… Axel Nennker
- Re: [jose] Platform Support for JWA Crypto Algori… Matt Miller (mamille2)
- Re: [jose] Platform Support for JWA Crypto Algori… Wan-Teh Chang
- Re: [jose] Platform Support for JWA Crypto Algori… Axel Nennker
- Re: [jose] Platform Support for JWA Crypto Algori… Mike Jones
- Re: [jose] NIST Concat KDF Manger, James H
- Re: [jose] NIST Concat KDF Richard L. Barnes
- Re: [jose] NIST Concat KDF Michael Jones
- Re: [jose] NIST Concat KDF Manger, James H
- Re: [jose] NIST Concat KDF Michael Jones
- Re: [jose] NIST Concat KDF Richard L. Barnes