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

CJ Tjhai <cjt@post-quantum.com> Thu, 10 May 2018 20:20 UTC

Return-Path: <cjt@post-quantum.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 3C7A612DA26 for <cfrg@ietfa.amsl.com>; Thu, 10 May 2018 13:20:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Level:
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=post-quantum-com.20150623.gappssmtp.com
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 3PQX2uBpoF0Q for <cfrg@ietfa.amsl.com>; Thu, 10 May 2018 13:20:55 -0700 (PDT)
Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66DB9127698 for <cfrg@irtf.org>; Thu, 10 May 2018 13:20:55 -0700 (PDT)
Received: by mail-oi0-x242.google.com with SMTP id b130-v6so2880216oif.12 for <cfrg@irtf.org>; Thu, 10 May 2018 13:20:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=post-quantum-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=grrZhPexKkSjfYS6xFoxD7z015sd4q69hNTDga74pCk=; b=CAG8dkPr1DRWSZx9pYQRi35mzy+SeNZkuXftobG+0QvBlwFf3RAv/VsrmLBEtkstDv veJNZsKobseqEc5A6BLAOVCq6KlQpkIXy1pwzak18qF4YLdjXMHdQhQJhazojWN1wVaH W9vdQMR/+kLzLksL8BzzIOFMD2Zjm/MXJTNAGZv6Z8rDUhvMVzmL22yo7I+9Lxq2wRvy Z8xNlnJTJilzlcqjaCFbjZH7g0vCSrFFXFQqxskM3K3zDs1J3dbd1CHRQvfByOj/NhUY IEZK0yw7UJhhcCgTiMUyDyn0oq3nuujQWDbiAQT7ems+tj14oYpWyNlCcXES3Yn1cB3G OIAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=grrZhPexKkSjfYS6xFoxD7z015sd4q69hNTDga74pCk=; b=RCWHC+NSrND7cPqq2HXuTG6l93Lm06Bo+2R+K3pdOFiAkUdRK5VABTV1eOE4/2mlgP dc+SOaXTxctukJdSt4sgZVeM2W0jkNq5+x5Ax6nqC57X1M1lQuNJd78eLe43qXky1fBj UvgJOkDAAqVaegHylnWvjR7LhCXLMzNUWkLFIpPO3b/hajz46hYg7WVTjEs4gtZuXzSt BHdpuDpNBP26BaoHF3dIqjAgyd0KlxHWd8fLwUe5//Zl022AWIL5pbs1PCFp5CUy1wKj BKHarluktY1Ky+1JMPjCoyvJvcHqVYflg61vqnAGuShmtXINxrMAlsH5qVvv24WR2y3w mVpQ==
X-Gm-Message-State: ALKqPwf9S6yIz4CcJ69cseUbpSoragTmFqkU40s+ts3oYj1wsf+5xYmS isheH/IwGJ8uKWYwjV0QJna+vtsvakSeqIFfwzix0g==
X-Google-Smtp-Source: AB8JxZrPAJGMji0BGbFQ9qTqdVYtxvQqx755MHqK1MZQ5fPEhq9bQ7xWVOHmSXpNvdwipPH0KozGZfflaWtNtUa6WhU=
X-Received: by 2002:aca:130e:: with SMTP id e14-v6mr1598832oii.33.1525983654505; Thu, 10 May 2018 13:20:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a9d:1bae:0:0:0:0:0 with HTTP; Thu, 10 May 2018 13:20:53 -0700 (PDT)
In-Reply-To: <07d901d3e87e$91f85250$b5e8f6f0$@com>
References: <07d901d3e87e$91f85250$b5e8f6f0$@com>
From: CJ Tjhai <cjt@post-quantum.com>
Date: Thu, 10 May 2018 21:20:53 +0100
Message-ID: <CANs=h-XUxvaTeWjwO9XKD20iSc0MLmicsTN2vs0tEh2WCoBSDw@mail.gmail.com>
To: John Nix <jnix@vobal.com>
Cc: cfrg@irtf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/zXbPAJq69aL0136XfdsbHJvL3CI>
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 20:20:57 -0000

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 <jnix@vobal.com> wrote:
> 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 mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>