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

Jim Schaad <ietf@augustcellars.com> Thu, 10 May 2018 18:05 UTC

From: Jim Schaad <ietf@augustcellars.com>
To: 'John Nix' <jnix@vobal.com>, cfrg@irtf.org
References: <07d901d3e87e$91f85250$b5e8f6f0$@com>
In-Reply-To: <07d901d3e87e$91f85250$b5e8f6f0$@com>
Date: Thu, 10 May 2018 11:05:11 -0700
Message-ID: <00bb01d3e889$721db730$56592590$@augustcellars.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00BC_01D3E84E.C5BF7B70"
Thread-Index: AQHuPJJEbx0OXv7RI0ajYRveciO9faP0mZKg
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/mWJTbgKRYYMHeby3n1QUV0sgt9g>
Subject: Re: [Cfrg] Example ECDH from WiFi Alliance standard failing with BouncyCastle ...
Precedence: list

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 <cfrg-bounces@irtf.org> On Behalf Of John Nix
Sent: Thursday, May 10, 2018 9:47 AM
To: cfrg@irtf.org
Subject: [Cfrg] Example ECDH from WiFi Alliance standard failing with
BouncyCastle ...

 

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

[Cfrg] Example ECDH from WiFi Alliance standard f… John Nix
Re: [Cfrg] Example ECDH from WiFi Alliance standa… Jim Schaad
Re: [Cfrg] Example ECDH from WiFi Alliance standa… John Nix
Re: [Cfrg] Example ECDH from WiFi Alliance standa… CJ Tjhai