> On Dec 3, 2015, at 11:04, Tommy Wang <[email protected]> wrote: > > 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. >
The text says "in a manner similar to ... [RFC2631]" -- not that you use RFC2631. > 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? > ConcatKDF is always used, as indicted in RFC 7518 § 4.6. The apv and apu are not supplied, which therefore means the PartyUInfo and PartyVInfo should both be 0x0000, as indicated in RFC 7518 § 4.6.2. You're getting some push back here because multiple implementations were involved in producing this document. If these truly are wrong, then we've got at least a few implementation that are wrong. -- - m&m Matt Miller Cisco Systems, Inc. > 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
