I am referencing the last paragraph of 4.6.2 of RFC7518: "Alternatively, applications MAY conduct key derivation in a manner similar to "Diffie-Hellman Key Agreement Method" [RFC2631]: in that case, the "apu" parameter MAY either be omitted or represent a random 512-bit value (analogous to PartyAInfo in Ephemeral-Static mode in RFC 2631) and the "apv" parameter SHOULD NOT be present."
Given that the example in RFC7520 section 5.5 does not provide an apu or apv, I had guessed that the DH Key Agreement method was used to generate the derived key, rather than ConcatKDF. I was able to verify the example in Appendix C of RFC7518 using the ConcatKDF key derivation where apv/apu were specified. ECDH was used to arrive at a shared secret in both cases. Do the examples in RFC7520 section 5.4/5.5 use ConcatKDF to derive the CEK? If so, what were the supplied apu/apv values for the otherinfo generation? On Thursday, December 3, 2015, Brian Campbell <[email protected]> wrote: > > Take a look again at http://tools.ietf.org/html/rfc7518#section-4.6, which > defines JOSE's ECDH-ES key agreement. A couple things of note are that it > references RFC6090 (not RFC2631) and ConcatKDF key derivation is always done > on the shared secret established through the ECDH algorithm. > > The Example ECDH-ES Key Agreement Computation at > http://tools.ietf.org/html/rfc7518#appendix-C might also be useful. > > > > On Thu, Dec 3, 2015 at 2:22 AM, Tommy Wang <[email protected]> wrote: >> >> Looking for some guidance on how the ECDH-ES Key Agreement (5.5.2) >> derived the CEK: >> >> hzHdlfQIAEehb8Hrd_mFRhKsKLEzPfshfXs9l6areCc >> >> No apv/apu values were provided leading me to believe that it was not >> derived using ConcatKDF. >> >> I tried to implement via D-H Key Agreement (RFC2631) with no >> partyAInfo but was not able to arrive at the same CEK. >> >> I used the following OIDS: >> >> OIDS = { >> 'A128CBC-HS256': '2.16.840.1.101.3.4.1.2', >> 'A192CBC-HS384': '2.16.840.1.101.3.4.1.22', >> 'A256CBC-HS512': '2.16.840.1.101.3.4.1.42', >> 'A128GCM': '2.16.840.1.101.3.4.1.6', >> 'A192GCM': '2.16.840.1.101.3.4.1.26', >> 'A256GCM': '2.16.840.1.101.3.4.1.46', >> } >> >> And the following pyasn1: >> >> from pyasn1.type import univ, namedtype, tag, constraint >> from pyasn1.codec.der import encoder >> import hashlib >> >> class Counter(univ.OctetString): >> subtypeSpec = constraint.ValueSizeConstraint(4, 4) >> >> class KeySpecificInfo(univ.Sequence): >> componentType = namedtype.NamedTypes( >> namedtype.NamedType('algorithm', univ.ObjectIdentifier()), >> namedtype.NamedType('counter', Counter()) >> ) >> >> class OtherInfo(univ.Sequence): >> componentType = namedtype.NamedTypes( >> namedtype.NamedType('keyInfo', KeySpecificInfo()), >> namedtype.OptionalNamedType('partyAInfo', univ.OctetString().subtype( >> explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 0) >> )), >> namedtype.NamedType('suppPubInfo', univ.OctetString().subtype( >> explicitTag=tag.Tag(tag.tagClassContext, tag.tagFormatSimple, 2) >> )) >> ) >> >> def km(alg, zz, n): >> oid = OIDS[alg] >> ainfo = None >> pinfo = 128 >> k = KeySpecificInfo() >> k.setComponentByName('algorithm', oid) >> k.setComponentByName('counter', struct.pack('>I', n)) >> o = OtherInfo() >> o.setComponentByName('keyInfo', k) >> o.setComponentByName('suppPubInfo', struct.pack('>I', pinfo)) >> o = encoder.encode(o) >> return hashlib.sha1(zz + o).digest() >> >> zz was derived using cryptography's EC key exchange. >> >> _______________________________________________ >> jose mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/jose > > _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
