[openpgp] [PATCH] Fix signature packet description for EdDSA

NIIBE Yutaka <gniibe@fsij.org> Wed, 13 May 2020 03:14 UTC

Return-Path: <gniibe@fsij.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 633913A07B6 for <openpgp@ietfa.amsl.com>; Tue, 12 May 2020 20:14:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fsij.org
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VwG8XTI2BnOl for <openpgp@ietfa.amsl.com>; Tue, 12 May 2020 20:14:10 -0700 (PDT)
Received: from akagi.fsij.org (akagi.fsij.org [IPv6:2001:4b98:dc0:41:216:3eff:fe1a:6542]) (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 400E73A0484 for <openpgp@ietf.org>; Tue, 12 May 2020 20:14:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fsij.org; s=main; h=Content-Type:MIME-Version:Message-ID:Date:Subject:To:From:Sender: Reply-To:Cc:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=sO3wB7uDnTsOXTqMrWHl7GqqK7NsV3Jya1fIXz9x8uE=; b=CZ3hDBn0uF8+46zRlTae0FzrxH kbHMAef3Re1ZTI+OSVNsnyBxte+Mpy9zr5INye3tebVsDDS1sUV6wnXwCFPUKi3a29dZ/XKjU6Uqm dGFyDxq66SBCMBaeNBOqowhLnYweyF2NuJStDAngn6c12o/t/AEpe24q+AJajsO4aS4ZdWZLTuUI6 gTFbaLfrzict0XIZXi0KpW1m5PfZARtLwDyaThIRXp4y92HYH3FKVihA434dmETMI66Z0luuOGjSN Fp0X+N4uwvMUHJgqvyPMi7u0yvBza4z8/9NJgr/KcFxqWLSJ9IRKmMHu7bSoRVF4/92Yqdez7Spw4 3zsOjUYQ==;
Received: from ([] helo=iwagami.gniibe.org) by akagi.fsij.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <gniibe@fsij.org>) id 1jYhqQ-0004Fv-9U; Wed, 13 May 2020 05:14:07 +0200
Received: by iwagami.gniibe.org (sSMTP sendmail emulation); Wed, 13 May 2020 12:14:00 +0900
From: NIIBE Yutaka <gniibe@fsij.org>
To: openpgp@ietf.org
Date: Wed, 13 May 2020 12:14:00 +0900
Message-ID: <87imh0ttl3.fsf@iwagami.gniibe.org>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/Za0hhS2-pW3loHojK4U2r_MZt_c>
Subject: [openpgp] [PATCH] Fix signature packet description for EdDSA
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 13 May 2020 03:14:12 -0000


Last year, I proposed a change of introducing "Simply, Octet String"
(SOS), so that we can add modern ECC Curves, which native encoding is
(usually) little endian.

Then, I modified libgcrypt (master) to accommodate accordingly, and
testing GnuPG with my branch:


Firstly, before the introduction of SOS, let me point out the problem
(again), with a possible fix.

EdDSA signature has two fields: R and S.  R is an EC point, and S is an
integer.  An EC point can be expressed by its y coordinate and sign,
"compressed" (meaning omitting x coordinate).

In the native format of Ed25519 or Ed448, an EC point is encoded in
fixed size little endian, and an integer is also encoded in fixed size
little endian.

In OpenPGP, both fields are represented (ab)using MPI format, which
assumes big endian integer.  When composing MPI, a value is
re-interpreted, which is considered bad.  We have real problem here,
because handling MPI mandates removing leading zeros.  For R, we use the
special prefix 0x40 to avoid removal of leading zeros.  For S, it is the
responsibility of implementations to recover removed zeros at the front.

And...  Here is the change of mine for the specification.

diff --git a/rfc4880bis.md b/rfc4880bis.md
index fbad178..710dd05 100644
--- a/rfc4880bis.md
+++ b/rfc4880bis.md
@@ -1263,13 +1263,13 @@ The body of a V4 or V5 Signature packet contains:
     Algorithm-Specific Fields for EdDSA signatures:
-      * MPI of EdDSA compressed value r.
+      * MPI of an EC point r.
-      * MPI of EdDSA compressed value s.
+      * EdDSA value s, in MPI, in the little endian representation.
-The compressed version of R and S for use with EdDSA is described in
-[](#RFC8032).  A version 3 signature MUST NOT be created
-and MUST NOT be used with EdDSA.
+The format of R and S for use with EdDSA is described in [](#RFC8032).
+A version 3 signature MUST NOT be created and MUST NOT be used with
 The concatenation of the data being signed and the signature data from
 the version number through the hashed subpacket data (inclusive) is

The first change is that: In EdDSA, R is an EC point (not an integer
like ECDSA).  The (compressed) format of an EC point in EdDSA is
described at another part in the document.

The second change is that: In EdDSA, S is an integer.  An expression
"compressed" is not relevant here.  It is little endian in the native
semantics, but is put in MPI.  Well, the description of mine here is
still too short and ambiguous, which is needed fix later.