[openpgp] Catch 22 in ECC support of OpenPGP?
Werner Koch <wk@gnupg.org> Fri, 31 January 2014 08:56 UTC
Return-Path: <wk@gnupg.org>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 786E51A0575 for <openpgp@ietfa.amsl.com>; Fri, 31 Jan 2014 00:56:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 sKp9MB7s8BrW for <openpgp@ietfa.amsl.com>; Fri, 31 Jan 2014 00:56:26 -0800 (PST)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [217.69.77.222]) by ietfa.amsl.com (Postfix) with ESMTP id 227671A056A for <openpgp@ietf.org>; Fri, 31 Jan 2014 00:56:25 -0800 (PST)
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.80 #2 (Debian)) id 1W99td-0005rY-OQ for <openpgp@ietf.org>; Fri, 31 Jan 2014 09:56:21 +0100
Received: from wk by vigenere.g10code.de with local (Exim 4.82 #3 (Debian)) id 1W99m5-0004z2-BX for <openpgp@ietf.org>; Fri, 31 Jan 2014 09:48:33 +0100
From: Werner Koch <wk@gnupg.org>
To: openpgp@ietf.org
Organisation: g10 Code GmbH
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
OpenPGP: id=1E42B367; url=finger:wk@g10code.com
Date: Fri, 31 Jan 2014 09:48:33 +0100
Message-ID: <87iot0y1su.fsf@vigenere.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [openpgp] Catch 22 in ECC support of OpenPGP?
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Fri, 31 Jan 2014 08:56:29 -0000
Hi, [gniibe asked on the gnupg-devel list on how to support EdDSA. We better continue the discussion here.] On Fri, 31 Jan 2014 04:46, gniibe@fsij.org said: > I think that adding new signature scheme requires its algorithm ID. Right, for EdDSA we should have a new id. Yesterday I changed the GnuPG code and replaced the EdDSA hacks with new experimental algorithm id. The code is not finished and actually the whole ECC stuff is currently broken. I'll fix that soon. For EdDSA we need a new RFC to have the IANA assign a new algorithm id. While doing that we should also address two questions: 1. Shall we keep the OID field or shall we replace it with either a curve size parameter or maybe assign a single algorithm identifier for Ed25519/EdDSA? 2. Does the use of MPIs make sense? Bernstein defines the key as well as the signature material as octet strings and not as MPIs. A reason to drop the OID field would be smaller key material which may help with key backup or direct use of the key. However, it complicates parsing because we would need two methods. I am fine with the OIDs (after all I suggested them) because for key backup we can use our own format. Such a format should be URI encoded for use in QR codes anyway. The problem with fitting an EdDSA key or signature material into an MPI is the usual leading zero problem. Thus for processing the red MPIs needs to be left-padded with zeroes up to the size indirecty specified by the OID. Note that we do not have the compression flag byte in plain EdDsA (but see below). For GnuPG/Libgcrypt this is not a big problem because we already have code in place to do that. New OpenPGP implementations may benefit from a simpler scheme. Related to question 1, a length byte could also be used to distinguish between different curves (i.e. Ed25519 and Curve41417). RFC-4880 describes the key material as a series of MPIs, which would rule out the above idea. However, RFC-6637 already uses non-MPIs for the OID and the KDF params. > (1) Possible algorithm ID 22 for ECDH+ECDSA: > http://www.ietf.org/mail-archive/web/openpgp/current/msg07163.html I am not in favor of mixing them. Encryption, and in particular DH, is different from signing. Having different algorithms ids also helps to avoid mixing encryption and signing keys due to implicit capabilities. > (2) Possible algorithm ID 22 for EdDSA: > http://www.ietf.org/mail-archive/web/openpgp/current/msg07194.html Before we can request the assignment of a new algo id, we need to write the specs. This is why I am currently using 105 for EdDSA. Some of you may have noticed that the CFRG (the IRTF crypto research group) is currently discussing standardization of non-Weierstrass curves (e.g. Curve25519 an its variants). Watson Ladd is working on an I-D[1]. The TLS WG is also discussing these curves. There are many ideas floating around and it would be useful to wait until we have a clear picture. This will help to solve the problem of missing standard documents for the Bernstein (aka Chicago) curves. The available papers are not suitable for normative use in an RFC (maybe with the exception of the Ed25519 paper). Of course we could informally agree on an algorithm id for EdDSA, as we always did in the OpenPGP WG. However, a new algorithm id is not sufficient as long as we do not have answers to the above questions. We better go in lock-step with the Ladd I-D. Is there anyone with free time to write an I-D? Shouldn't we continue this discussing at the IETF OpenPGP mailing list? Salam-Shalom, Werner [1] http://www.ietf.org/id/draft-ladd-safecurves-03.txt -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
- Re: [openpgp] Catch 22 in ECC support of OpenPGP? Andrey Jivsov
- [openpgp] Catch 22 in ECC support of OpenPGP? Werner Koch
- Re: [openpgp] Catch 22 in ECC support of OpenPGP? Jon Callas
- Re: [openpgp] Catch 22 in ECC support of OpenPGP? Werner Koch
- Re: [openpgp] Catch 22 in ECC support of OpenPGP? Jon Callas
- Re: [openpgp] Catch 22 in ECC support of OpenPGP? Andrey Jivsov