Re: [jose] Platform Support for JWA Crypto Algorithms
Axel Nennker <ignisvulpis@gmail.com> Wed, 31 October 2012 08:32 UTC
Return-Path: <ignisvulpis@gmail.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 CCB0C21F870B for <jose@ietfa.amsl.com>; Wed, 31 Oct 2012 01:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 dhdapZIMVSYK for <jose@ietfa.amsl.com>; Wed, 31 Oct 2012 01:32:20 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 7C4F321F8735 for <jose@ietf.org>; Wed, 31 Oct 2012 01:32:19 -0700 (PDT)
Received: by mail-wg0-f44.google.com with SMTP id dr13so549925wgb.13 for <jose@ietf.org>; Wed, 31 Oct 2012 01:32:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pSr7ISRjRU1eg3U40U3ke7hRbWQX59VzMPCPwIdWzz4=; b=u1AioFIXOwGnWIVXJB0CQgp2kk5c79Yl3GfbVmMyULEtU4GcqtdiIQQfjVwnKkORS+ NpDwx7GNrRP5HGPZd0LkZZ1RGpvhP8XlYaByzoH0kUhF6p+fHTRqMSkQ9S5QX35EZbnK 67KEdWEYVygt0fZcSvEhxYFJwserJXCjRSThDqiGai9IyaPyHnibusUCH65s12KxuJQ+ 5lktS6BUT6saWxjEJkUqsMus5V++FCdJZMRjHub3QvKtQZ59KhFkGNk6Amnmw3IGO8e7 zk6EIpFuH11xUpzrUBCti8cYazh5OtaQ546hbkN/FFdOmeGTTc7vtVDitftMbyd3aNj8 zi9A==
MIME-Version: 1.0
Received: by 10.180.82.34 with SMTP id f2mr1051736wiy.17.1351672337615; Wed, 31 Oct 2012 01:32:17 -0700 (PDT)
Received: by 10.216.54.130 with HTTP; Wed, 31 Oct 2012 01:32:17 -0700 (PDT)
In-Reply-To: <BF7E36B9C495A6468E8EC573603ED94115076A6F@xmb-aln-x11.cisco.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> <4E1F6AAD24975D4BA5B16804296739436688296F@TK5EX14MBXC285.redmond.corp.microsoft.com> <BF7E36B9C495A6468E8EC573603ED94115076A6F@xmb-aln-x11.cisco.com>
Date: Wed, 31 Oct 2012 09:32:17 +0100
Message-ID: <CAHcDwFyk9DvC18NKzdtb4p0yQW6j4HYbm+KJmkphU965bcVdnw@mail.gmail.com>
From: Axel Nennker <ignisvulpis@gmail.com>
To: "Matt Miller (mamille2)" <mamille2@cisco.com>
Content-Type: multipart/alternative; boundary="f46d044289f689495404cd56bdd8"
Cc: Mike Jones <Michael.Jones@microsoft.com>, "<public-webcrypto@w3.org>" <public-webcrypto@w3.org>, "<jose@ietf.org>" <jose@ietf.org>, "<Axel.Nennker@telekom.de>" <Axel.Nennker@telekom.de>
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: Wed, 31 Oct 2012 08:32:21 -0000
I think that https://tools.ietf.org/html/rfc2898 ( https://en.wikipedia.org/wiki/PBKDF2) is a better choice than the concat-kdf from NIST. PBKDF2 does not care whether the password consists of printable characters or whether it is a randomly generated byte strink like our CMK. There is no need to base64url the key/cmk. In the wikipedia article is a list of implementations which sounds much better than our current rows in our crypto-algs compat-table. I suggest we use PBKDF2(HMACSHA1, cmk, iv||"Integrity", 1000) to generate cik and PBKDF2(SHA256, cmk, iv||"Encryption", 1000) to generate the cek. "||" is concatenation. HMACSHA1 as default (MTI) and HMACSHA256 as recommended?! Or we could use my earlier proposal to define the first interation of the concat-kdf as the default for our currently defined encryption algorithms. CIK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 49, 57, 50, 67, 66, 67, 43, 72, 83, 50, 53, 54, 73, 110, 116, 101, 103, 114, 105, 116, 121)[0-255] CEK = SHA256(0, 0, 0, 1, CMK, 0, 0, 1, 0, 65, 50, 53, 54, 67, 66, 67, 43, 72, 83, 50, 53, 54, 69, 110, 99, 114, 121, 112, 116, 105, 111, 110)[0-255] or something along those lines... Axel 2012/10/30 Matt Miller (mamille2) <mamille2@cisco.com> > > On Oct 29, 2012, at 4:24 PM, Mike Jones <Michael.Jones@microsoft.com> > 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.4and > http://tools.ietf.org/html/draft-ietf-jose-json-web-encryption-06#appendix-A.5to 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 < mamille2@cisco.com > > Cisco Systems, Inc. > > -- 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.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. > >> > >> 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.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> [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 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