[Openid-specs-ab] ECDH+KDF example (was Re: Spec Call note 5-Aug-2013)

Mike Jones Michael.Jones at microsoft.com
Mon Aug 26 18:17:22 UTC 2013


Hi Brian,

I was about to apply your values below to the specs, but discovered what a appears to be an error in the values below, and potentially in your computation.  In particular, the receiver's JWK should be:
  {"kty":"EC",
   "crv":"P-256",
   "x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
   "y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
   "d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"
  }
-- not the value that you listed below, which was a copy of the sender's ephemeral key.

Can you please redo the computation with the correct receiver's key and send us the results?

				Thanks again,
				-- Mike

-----Original Message-----
From: Brian Campbell [mailto:bcampbell at pingidentity.com] 
Sent: Thursday, August 08, 2013 9:30 AM
To: Mike Jones
Cc: Edmund Jay; openid-specs-ab at lists.openid.net List
Subject: Re: [Openid-specs-ab] ECDH+KDF example (was Re: Spec Call note 5-Aug-2013)

Here's about as much (hopefully useful) output from various stages of the process as I can get to. Attached as text file too, which might be easier to read, if gmail decides to reformat things.

[ECDH w/ JWA -14 KDF example] Receiver JWK:
{"kty":"EC",
 "crv":"P-256",
 "x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
 "y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
 "d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"
}
[ECDH w/ JWA -14 KDF example] Ephemeral JWK:
{"kty":"EC",
 "crv":"P-256",
 "x":"weNJy2HscCSM6AEDTDg04biOvhFhyyWvOHQfeF_PxMQ",
 "y":"e8lnCO-AlStT-NJVX-crhB7QRYhiix03illJOVAOyck",
 "d":"VEmDZpDXXK8p8N0Cndsxs924q6nS1RXFASRl6BfUqdw"
}
[ECDH w/ JWA -14 KDF example] Output of sender's ECDH (z): [158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140, 254, 144,
196](32bytes/256bits) | base64url encoded:
nlbZHYFxNdNyg0KDv4QmnPsxbqPagGpI9tqneYz-kMQ
[ECDH w/ JWA -14 KDF example] Output of receiver ECDH (z): [158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140, 254, 144,
196](32bytes/256bits) | base64url encoded:
nlbZHYFxNdNyg0KDv4QmnPsxbqPagGpI9tqneYz-kMQ
[ECDH w/ JWA -14 KDF example] keydatalen: 128 [ECDH w/ JWA -14 KDF example] algorithmId: A128GCM [ECDH w/ JWA -14 KDF example] apu: QWxpY2U | decoded: Alice [ECDH w/ JWA -14 KDF example] apv: Qm9i | decoded: Bob [ConcatKeyDerivationFunction] Hash Algorithm: SHA-256 with hashlen: 256 bits [ConcatKeyDerivationFunction] KDF:
[ConcatKeyDerivationFunction]   z: [158, 86, 217, 29, 129, 113, 53,
211, 114, 131, 66, 131, 191, 132, 38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140, 254, 144, 196](32bytes/256bits)
| base64url encoded: nlbZHYFxNdNyg0KDv4QmnPsxbqPagGpI9tqneYz-kMQ
[ConcatKeyDerivationFunction]   keydatalen: 128
[ConcatKeyDerivationFunction]   algorithmId: [65, 49, 50, 56, 71, 67,
77](7bytes/56bits) | base64url encoded: QTEyOEdDTQ
[ConcatKeyDerivationFunction]   partyUInfo: [0, 0, 0, 5, 65, 108, 105,
99, 101](9bytes/72bits) | base64url encoded: AAAABUFsaWNl
[ConcatKeyDerivationFunction]   suppPubInfo: [0, 0, 0,
128](4bytes/32bits) | base64url encoded: AAAAgA
[ConcatKeyDerivationFunction]   suppPrivInfo: [](0bytes/0bits) |
base64url encoded:
[ConcatKeyDerivationFunction] reps: 1
[ConcatKeyDerivationFunction] otherInfo: [65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0,
128](27bytes/216bits) | base64url encoded:
QTEyOEdDTQAAAAVBbGljZQAAAANCb2IAAACA
[ConcatKeyDerivationFunction] rep 1 hashing [ConcatKeyDerivationFunction]  counter: [65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0,
128](27bytes/216bits) | base64url encoded:
QTEyOEdDTQAAAAVBbGljZQAAAANCb2IAAACA
[ConcatKeyDerivationFunction]  z: [158, 86, 217, 29, 129, 113, 53, 211, 114, 131, 66, 131, 191, 132, 38, 156, 251, 49, 110, 163, 218, 128, 106, 72, 246, 218, 167, 121, 140, 254, 144, 196](32bytes/256bits)
| base64url encoded: nlbZHYFxNdNyg0KDv4QmnPsxbqPagGpI9tqneYz-kMQ
[ConcatKeyDerivationFunction]  otherInfo: [65, 49, 50, 56, 71, 67, 77, 0, 0, 0, 5, 65, 108, 105, 99, 101, 0, 0, 0, 3, 66, 111, 98, 0, 0, 0,
128](27bytes/216bits) | base64url encoded:
QTEyOEdDTQAAAAVBbGljZQAAAANCb2IAAACA
[ConcatKeyDerivationFunction]  k(1): [186, 193, 41, 192, 82, 2, 254, 170, 230, 4, 76, 103, 180, 92, 49, 48, 92, 55, 131, 15, 80, 148, 215, 60, 65, 196, 187, 233, 163, 142, 6, 218](32bytes/256bits) | base64url
encoded: usEpwFIC_qrmBExntFwxMFw3gw9QlNc8QcS76aOOBto
[ConcatKeyDerivationFunction] derived key material: [186, 193, 41, 192, 82, 2, 254, 170, 230, 4, 76, 103, 180, 92, 49, 48, 92, 55, 131, 15, 80, 148, 215, 60, 65, 196, 187, 233, 163, 142, 6,
218](32bytes/256bits) | base64url encoded:
usEpwFIC_qrmBExntFwxMFw3gw9QlNc8QcS76aOOBto
[ConcatKeyDerivationFunction] first 128 bits of derived key material:
[186, 193, 41, 192, 82, 2, 254, 170, 230, 4, 76, 103, 180, 92, 49,
48](16bytes/128bits) | base64url encoded: usEpwFIC_qrmBExntFwxMA [ConcatKeyDerivationFunction] final derived key material: [186, 193, 41, 192, 82, 2, 254, 170, 230, 4, 76, 103, 180, 92, 49,
48](16bytes/128bits) | base64url encoded: usEpwFIC_qrmBExntFwxMA [ECDH w/ JWA -14 KDF example] Derived Key from KDF:[186, 193, 41, 192, 82, 2, 254, 170, 230, 4, 76, 103, 180, 92, 49, 48](16bytes/128bits) | base64url encoded: usEpwFIC_qrmBExntFwxMA

On Wed, Aug 7, 2013 at 7:23 PM, Mike Jones <Michael.Jones at microsoft.com> wrote:
> No, I'm not going to look at it until next week.  If you could also 
> provide the hash input used in the kdf, that could help narrow down 
> the potential differences.
>
> -- Mike
>
> ________________________________
> From: Brian Campbell
> Sent: 8/7/2013 7:07 PM
> To: Mike Jones
> Cc: Edmund Jay; openid-specs-ab at lists.openid.net List
>
> Subject: Re: [Openid-specs-ab] ECDH+KDF example (was Re: Spec Call 
> note
> 5-Aug-2013)
>
> Sure (but you are supposed to be on vacation so you shouldn't look at 
> it until next week),
>
> z - (the output from the ECDH key agreement):
> nlbZHYFxNdNyg0KDv4QmnPsxbqPagGpI9tqneYz-kMQ
>
> and the final output is usEpwFIC_qrmBExntFwxMA
>
> both are base64url encodings of the octets
>
> If you need other intermediate values, just let me know. I'll need to 
> instrument a little to get at them.
>
>
> On Wed, Aug 7, 2013 at 4:51 PM, Mike Jones 
> <Michael.Jones at microsoft.com>
> wrote:
>>
>> Can you guys send me the intermediate results from your computations?
>>
>> Thanks,
>> -- Mike
>>
>> ________________________________
>> From: Brian Campbell
>> Sent: 8/7/2013 6:47 PM
>> To: Edmund Jay
>> Cc: openid-specs-ab at lists.openid.net List
>>
>> Subject: Re: [Openid-specs-ab] ECDH+KDF example (was Re: Spec Call 
>> note
>> 5-Aug-2013)
>>
>> That's exactly the same result I'm getting.
>>
>> On Wed, Aug 7, 2013 at 3:26 PM, Edmund Jay <ejay at mgi1.com> wrote:
>> > Brian,
>> >
>> > I haven't been able to reproduce the ECDH-ES  results either.
>> > I'm getting the base64url value usEpwFIC_qrmBExntFwxMA or hex 
>> > 0xBAC129C05202FEAAE6044C67B45C3130.
>> > Is that anywhere close to what you're getting?
>> >
>> > -- Edmund
>> >
>> >
>> > ________________________________
>> > From: Nat Sakimura (NRI) <n-sakimura at nri.co.jp>
>> > To: Brian Campbell <bcampbell at pingidentity.com>
>> > Cc: "openid-specs-ab at lists.openid.net List"
>> > <openid-specs-ab at lists.openid.net>
>> > Sent: Monday, August 5, 2013 5:23 PM
>> > Subject: Re: [Openid-specs-ab] ECDH+KDF example (was Re: Spec Call 
>> > note
>> > 5-Aug-2013)
>> >
>> > As far as I know, Edmund jsut started working on it.
>> > Let us see how it turns out.
>> >
>> > Nat
>> >
>> > (2013/08/06 9:16), Brian Campbell wrote:
>> >>> New examples in JWT and JOSE specs
>> >>> -----------------------------------
>> >>> Edmund will start working on it right after this call.
>> >>>
>> >> I've been able to verify the new nested JWT example.
>> >>
>> >> But I haven't been able to reproduce the same results as in the 
>> >> new example with ECDH-ES Key Agreement and Concat KDF at
>> >>
>> >>
>> >> http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-14#
>> >> appendix-D
>> >>
>> >> If Edmund or anyone is working on it, I'd love to share notes or 
>> >> intermediate results or code to try and figure it out.
>> >>
>> >> Mike is on vacation this week so isn't around to defend his 
>> >> examples :)
>> >>
>> >
>> >
>> > --
>> > Nat Sakimura (n-sakimura at nri.co.jp) Nomura Research Institute, Ltd.
>> > Tel:+81-3-6274-1412 Fax:+81-3-6274-1547
>> >
>> >
>> > 本メールに含まれる情報は機密情報であり、宛先に記載されている方のみに送信することを意図しております。意図された受取人以外の方によるこれらの情報の開示、複製、再配布や転送など一切の利用が禁止されています。誤って本メールを受信された場合は、申し訳ございませんが、送信者までお知らせいただき、受信されたメールを削除していただきますようお願い致します。
>> > PLEASE READ:
>> > The information contained in this e-mail is confidential and intended
>> > for
>> > the named recipient(s) only.
>> > If you are not an intended recipient of this e-mail, you are hereby
>> > notified
>> > that any review, dissemination, distribution or duplication of this
>> > message
>> > is strictly prohibited. If you have received this message in error,
>> > please
>> > notify the sender immediately and delete your copy from your system.
>> >
>> > _______________________________________________
>> > Openid-specs-ab mailing list
>> > Openid-specs-ab at lists.openid.net
>> > http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> >
>> >
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>


More information about the Openid-specs-ab mailing list