Re: [openpgp] patch for EdDSA key packet formats

Taylor R Campbell <campbell+ietf-openpgp@mumble.net> Tue, 14 February 2017 17:26 UTC

Return-Path: <campbell@mumble.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D881129454 for <openpgp@ietfa.amsl.com>; Tue, 14 Feb 2017 09:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-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 9R_RCR2n9G_7 for <openpgp@ietfa.amsl.com>; Tue, 14 Feb 2017 09:26:53 -0800 (PST)
Received: from jupiter.mumble.net (jupiter.mumble.net [74.50.56.165]) (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 BF75B12941A for <openpgp@ietf.org>; Tue, 14 Feb 2017 09:26:53 -0800 (PST)
Received: by jupiter.mumble.net (Postfix, from userid 1014) id E85CB60A7A; Tue, 14 Feb 2017 17:26:43 +0000 (UTC)
From: Taylor R Campbell <campbell+ietf-openpgp@mumble.net>
To: NIIBE Yutaka <gniibe@fsij.org>
In-reply-to: <87y3x9yppw.fsf@fsij.org> (gniibe@fsij.org)
Date: Tue, 14 Feb 2017 17:26:52 +0000
Sender: Taylor R Campbell <campbell@mumble.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20170214172643.E85CB60A7A@jupiter.mumble.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/6e4UGpPD_el0Szbg7rq5qQZpCM0>
Cc: openpgp@ietf.org
Subject: Re: [openpgp] patch for EdDSA key packet formats
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Feb 2017 17:26:55 -0000

> Date: Tue, 14 Feb 2017 20:30:19 +0900
> From: NIIBE Yutaka <gniibe@fsij.org>

Hi, Niibe-san!  Thanks for the review.

> > @@ -1936,8 +1936,9 @@ A version 4 packet contains:
> >             - the octets representing a curve OID, defined in
> >               section NN{FIXME};
> >  
> > -      - a MPI of an EC point representing a public key Q as described
> > -        under EdDSA Point Format below.
> > +      - a MPI, encoded as described under EdDSA Point Format, of an EC
> > +        point A, in the notation of [](#I-D.irtf-cfrg-eddsa),
> > +        Section 3.2 "Keys".
> 
> I think that the expression "an EC point A" would not be good.  In RFC
> 8032, Section 3.1 "Encoding" explains about ENC(), the little-endian
> encoding, and Section 3.2 "Keys" says:
> 
> 	The EdDSA public key is ENC(A).
> 
> ... where A is an EC point.
> 
> We put the prefix 0x40 to ENC(A), it is not entirely same of
> the notation of Section 3.2 "Keys".

Right, but in RFC 8032, the letter `A' does mean a point on the curve.
What my text says is that we encode the point A using the encoding
described below in the Section 13.3 `EdDSA Point Format'.  This is not
the same as storing the RFC 8032 public key, which is the point A
encoded as ENC(A).

It may be that the Section 13.3 `EdDSA Point Format' encoding is
actually 0x40 || ENC(A), but I'm not sure offhand.

> > @@ -2034,8 +2035,8 @@ The packet contains:
> >  
> >      Algorithm-Specific Fields for EdDSA keys:
> >  
> > -      - MPI of an integer representing the secret key, which is a
> > -        scalar of the public EC point.
> > +      - an opaque octet string k, in the notation of
> > +        [](#I-D.irtf-cfrg-eddsa), Section 3.2 "Keys".
> 
> Right.  It's not a scalar of the public EC point.  It is the one
> which generates the scalar.
> 
> In my opinion, "MPI of an integer representing the secret key" is not
> wrong.

You are probably right!  I'm afraid I neglected to write notes when I
prepared the patch, so I forgot where in the code I should have cited
for that.  Do you have a quick reference to the source code in
libgcrypt or gnupg that handles encoding this?