He's quoting from the NIST spec in which Concat is defined below. I realize
that our usage is common practice and I suspect there's no actual problem with
it, but given it violates the letter of the spec in which Concat is defined, I
felt that I needed to at least bring the issue to the attention of the working
group so that we can make an informed decision.
-- Mike
From: Jim Schaad [mailto:[email protected]]
Sent: Friday, July 27, 2012 5:56 PM
To: Mike Jones; [email protected]
Subject: RE: [jose] Open Issue: Multiple uses of the Concat KDF with the same
secret
Where did he get this idea? This is very common practice in many protocols
Jim
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]]<mailto:[mailto:[email protected]]> On Behalf
Of Mike Jones
Sent: Friday, July 27, 2012 3:44 PM
To: [email protected]<mailto:[email protected]>
Subject: [jose] Open Issue: Multiple uses of the Concat KDF with the same secret
In conversations during this week's W3C WebCrypto F2F, Vijay Bharadwaj pointed
out that using the same input secret to the Concat KDF twice, as we currently
do in JWA 4.12
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-04#page-16, is
prohibited. Rather than using two different labels with the same secret as TLS
does (in our case "Encryption" and "Integrity"), we're supposed to generate
enough key bits for both keys in one operation.
I'll add this to the set of Open Issues for us to discuss next week. Looking
forward to seeing many of you then!
-- Mike
P.S. BTW, the W3C WebCrypto WG wants to closely coordinate with JOSE, in part,
to ensure that the WebCrypto output - a set of JavaScript crypto APIs - will be
a great way to build JOSE implementations.
From: Vijay Bharadwaj
Sent: Tuesday, July 24, 2012 8:52 PM
To: Mike Jones
Subject: Key derivation and FIPS
The restriction I was talking about is in Section 5.8 of SP
800-56A<http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf>:
An Approved key derivation function (KDF) shall be used to derive secret keying
material from a shared secret. The output from a KDF shall only be used for
secret keying material, such as a symmetric key used for data encryption or
message integrity, a secret initialization vector, or a master key that will be
used to generate other keys (possibly using a different process). Non- secret
keying material (such as a non-secret initialization vector) shall not be
generated using the shared secret.
Each call to the KDF requires a freshly computed shared secret, and this shared
secret shall be zeroized immediately following its use. The derived secret
keying material shall be computed in its entirety before outputting any portion
of it. In schemes using only static keys, the freshly computed shared secret
may be the same as the previous shared secret. In these cases, the initiator
supplied nonce (NonceU, see Section 6.3) used in the scheme will vary so the
same keying material is not regenerated.
The derived secret keying material may be parsed into one or more keys or other
secret cryptographic keying material (for example, secret initialization
vectors). If Key Confirmation (KC) or implementation validation testing are to
be performed as specified in Section 8 or Section 5.2.3, respectively, then the
MAC key shall be formed from the first bits of the KDF output and zeroized
after its use (i.e., the MAC key shall not be used for purposes other than key
confirmation or implementation validation testing).
So as you can see, NIST pretty clearly advocates for the "generate a bunch of
bits and chop them up" approach. The first part is implemented in CNG by
causing BCryptDeriveKey to wipe the supplied shared secret.
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
