Re: [openpgp] patch for EdDSA key packet formats

NIIBE Yutaka <> Wed, 15 February 2017 03:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B48DA1294AA for <>; Tue, 14 Feb 2017 19:20:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rWls4uJecjzt for <>; Tue, 14 Feb 2017 19:20:37 -0800 (PST)
Received: from ( [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CC12B12945C for <>; Tue, 14 Feb 2017 19:20:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=main; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:Subject:Cc:To:From; bh=yE+H+HTn+iHL7H1liBu3muGCzLoqNBrDh8X7yLy3/SU=; b=cmNg6GRj3+XO+1l3wx5BVlN4tVEjBV+EdzhoDFoffBuPbIsFUT96Ao3bDsvCCX6J3x0jYXrztx5epgBfmfABDX4Vi8hFQgQlyyIV4jzGC8+3D+yVQx33+ggV05JuPxfpS5oeP1qNKgFVyn1CzwjyZBjepD9zv0teI8t49v2dxjzbjiPw2gscK/1g2fFVol3nKvAYn5n7SWudIv97Rchcy4p7ty6ZrF2alIevt2vdBcFPG/Pa+lD6RKfpI6Rp2IqtyG8awxRTaKUvQ5oULXabaEr046ZMGOG332Ak7fxu5Cpoxd6O80XmltV2YtbnZMokt+Q9MQaveuhEfjq3uDWC+Q==;
Received: from ([] by with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from <>) id 1cdq8v-0005pj-A0; Wed, 15 Feb 2017 04:20:35 +0100
Received: by (sSMTP sendmail emulation); Wed, 15 Feb 2017 12:20:28 +0900
From: NIIBE Yutaka <>
To: Taylor R Campbell <>
In-Reply-To: <>
References: <>
Date: Wed, 15 Feb 2017 12:20:28 +0900
Message-ID: <>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [openpgp] patch for EdDSA key packet formats
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 15 Feb 2017 03:20:40 -0000

Taylor R Campbell <> wrote:
> 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.

I believe this (0x40 || ENC(A)) is the `EdDSA Point Format' encoding.

> 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?

In GnuPG, secret keys are primarily handled by gpg-agent with libgcrypt.
And libgcrypt stores them in the format of SEXP [0].  So, GnuPG only
handles OpenPGP secret keys when importing/exporting in OpenPGP format.

For importing, we have the function parse_key in
gnupg/g10/parse-packet.c:2112 (in the release 2.1.18).  When secret key
is not protected, it is handled by the mpi_read function (at line 2526).
Here, in the code, the expression is "pk->pkey[i]", where pk and pkey
stand for "public key", but this is because of historical reason, it
means secret key materials.

And then, it is handled by the function transfer_secret_keys in
gnupg/g10/import.c:1788.  It composes SEXP around line 1917, by "%m"
format, which means MPI, to send gpg-agent.

Exporting is similar.  In the function do_key in
gnupg/g10/build-packet.c:354, non-protected secret key is
written by gpg_mpi_write at line 478.

So, for the GnuPG implementation, secret key is handled as MPI.  But I
think that this is basically due to its historical reason, when keys in
OpenPGP format were specified as MPI.

For specification, "an opaque octet string k" may be better.  I support
this, personally.

On the other hand, I don't know why the ECC format of

	04 || x || y

was described as MPI in RFC6637.  For me, it is an octet string composed
by two MPIs and the prefix.

[0] SEXP --- (S-expressions)