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

"John Nix" <jnix@vobal.com> Thu, 10 May 2018 18:12 UTC

Return-Path: <jnix@vobal.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658E71270A3 for <cfrg@ietfa.amsl.com>; Thu, 10 May 2018 11:12:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN0CDMui-dmL for <cfrg@ietfa.amsl.com>; Thu, 10 May 2018 11:12:18 -0700 (PDT)
Received: from atl4mhob10.registeredsite.com (atl4mhob10.registeredsite.com [209.17.115.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2327E126D73 for <cfrg@irtf.org>; Thu, 10 May 2018 11:12:18 -0700 (PDT)
Received: from mailpod.hostingplatform.com (atl4qobmail04pod0.registeredsite.com [10.30.71.206]) by atl4mhob10.registeredsite.com (8.14.4/8.14.4) with ESMTP id w4AICCoY028135 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <cfrg@irtf.org>; Thu, 10 May 2018 14:12:12 -0400
Received: (qmail 10475 invoked by uid 0); 10 May 2018 18:12:12 -0000
X-TCPREMOTEIP: 96.72.88.222
X-Authenticated-UID: jnix@vobal.com
Received: from unknown (HELO DESKTOPOABK2CF) (jnix@vobal.com@96.72.88.222) by 0 with ESMTPA; 10 May 2018 18:12:12 -0000
From: John Nix <jnix@vobal.com>
To: cfrg@irtf.org
References: <07d901d3e87e$91f85250$b5e8f6f0$@com> <00bb01d3e889$721db730$56592590$@augustcellars.com>
In-Reply-To: <00bb01d3e889$721db730$56592590$@augustcellars.com>
Date: Thu, 10 May 2018 13:12:11 -0500
Message-ID: <082c01d3e88a$6b301340$419039c0$@com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_082D_01D3E860.825A0B40"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHuPJJEbx0OXv7RI0ajYRveciO9faP0mZKggAAA5tA=
Content-Language: en-us
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/DpZpr-1MHXtNlOTXDcmyRlYdOY4>
Subject: Re: [Cfrg] Example ECDH from WiFi Alliance standard failing with BouncyCastle ...
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 May 2018 18:12:20 -0000

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:ietf@augustcellars.com] 
Sent: Thursday, May 10, 2018 1:05 PM
To: 'John Nix'; cfrg@irtf.org
Subject: RE: [Cfrg] Example ECDH from WiFi Alliance standard failing with
BouncyCastle ...

 

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