Subject: [Cfrg] Example ECDH from WiFi Alliance standard failing with BouncyCastle ...

From: "John Nix" <[email-masked]>
Date: Thu, 10 May 2018 11:47:23 -0500

Hi,

I am trying to reproduce an example for an ECDH key exchange with 3 PKI key
pairs from a new standard called "Device Provisioning Protocol" version 1.0.
It was just published about a month ago.

An important part of the standard is an ECDH key derivation of a secret
shared key "L" using three key pairs: Bi,bi  and Br,br and Pr,pr.  The
capital is the public (X,Y) and the lower case is private.

On page 48 and 49, the standard shows a ECDH key exchange with the 3 keys
combined to derived the common, secret shared key L:

                L = (pr + br) mod q * Bi = (Br + Pr) *bi

In Appendix A1, they show example calculations with example keys for NIST
P-256.  The private keys are:

bi: 15b2a83c 5a0a38b6 1f2aa820 0ee4994b 8afdc01c 58507d10 d0a38f7e edf051bb

br: 54ce181a 98525f21 7216f59b 245f60e9 df30ac7f 6b26c939 418cfc3c 42d1afa0 

pr: f798ed2e 19286f6a 6efe210b 1863badb 99af2a14 b497634d bfd2a973 94fb5aa5

Using BouncyCastle's Java EC code, I can reproduce one side of their example
calculation/result of L in Appendix A.1 which is:

L = (pr + br) mod q * Bi = fb737234 c973cc3a 36e64e51 70a32f12 089d198c
73c2fd85 a53d0b28 2530fd02 (X value only)

However, when I calculate L for the other side [ L = (Br + Pr) *bi ], I get
the different value:

L = (Br + Pr) * bi = 5c5002ad 3c8e3f6a 1403b42c cc15a303 54b5062b 2c283e10
3971953c 1262f161 (X value only)

So, the example key exchange calculation with the 3 keys is failing.  For
(Br + Pr), I have simply added the two X values and the two Y values from
the public keys Br and Pr.

My question is (i) does this look like a problem with BouncyCastle (or my
calculation), or (ii) is there some issue with the way the standard is
proposing conducting the key exchange?  I appreciate any feedback, or
someone else trying to reproduce/confirm the example calculation from the
WiFi Alliance.

Thanks, John

---

From: Jim Schaad <[email-masked]>
Date: Thu, 10 May 2018 11:05:11 -0700

I am not sure what curves you are using, however point addition is generally
not as simple as just adding the x and y values as the resulting value will
not be a point on the curve.

Jim

From: Cfrg <[email-masked]> On Behalf Of John Nix
Sent: Thursday, May 10, 2018 9:47 AM
To: [email-masked]
Subject: [Cfrg] Example ECDH from WiFi Alliance standard failing with
BouncyCastle ...

Hi,

 

Thanks, John

---

From: "John Nix" <[email-masked]>
Date: Thu, 10 May 2018 13:12:11 -0500

I now see, and the issue is clear and on me.  My simple addition of the
public keys (newbie attempt at point addition) was incorrect.  I appreciate
the feedback.

Thanks, John

From: Jim Schaad [mailto:[email-masked]] 
Sent: Thursday, May 10, 2018 1:05 PM
To: 'John Nix'; [email-masked]
Subject: RE: [Cfrg] Example ECDH from WiFi Alliance standard failing with
BouncyCastle ...

Jim

Hi,

 

Thanks, John

---

From: CJ Tjhai <[email-masked]>
Date: Thu, 10 May 2018 21:20:53 +0100

Hi John,

I believe the values in the specification are correct and so is the EC
implementation in BouncyCastle.

See the Java snippet in the following gist that I've created. I'm on
BouncyCastle version 1.58.

https://gist.github.com/ctjhai/e33982dd61a2d14d0b579b1ff4df88db

Cheers,
CJ

On 10 May 2018 at 17:47, John Nix <[email-masked]> wrote:
> pairs from a new standard called “Device Provisioning Protocol” version 1.0.
> shared key “L” using three key pairs: Bi,bi  and Br,br and Pr,pr.  The
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg
>