[git] gnupg-doc - branch, master, updated. 39662b50026c9339d374fdbef0c5de62e9c46837
by Werner Koch
cvs at cvs.gnupg.org
Wed Mar 11 17:13:52 CET 2015
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "The GnuPG website and other docs".
The branch, master has been updated
via 39662b50026c9339d374fdbef0c5de62e9c46837 (commit)
from 52ab1ee9c0cf0f600f4685b34bc80bee8af09bec (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 39662b50026c9339d374fdbef0c5de62e9c46837
Author: Werner Koch <wk at gnupg.org>
Date: Wed Mar 11 17:11:11 2015 +0100
drafts: Add eddsa-for-openpgp draft
This commit is -02 with some grammer fixes from Ladar Levison.
Unfortunately the history of earlier source files is lost.
diff --git a/.gitignore b/.gitignore
index bca1deb..ec7b6c5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -12,3 +12,4 @@ scratch/
/misc/blog.gnupg.org/index.html
/misc/blog.gnupg.org/20*.html
/misc/blog.gnupg.org/headlines.txt
+/misc/id/eddsa-for-openpgp/draft.txt
diff --git a/misc/id/common/reference.ED25519.xml b/misc/id/common/reference.ED25519.xml
new file mode 100644
index 0000000..fd1505b
--- /dev/null
+++ b/misc/id/common/reference.ED25519.xml
@@ -0,0 +1,27 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='ED25519'
+ target='http://dx.doi.org/10.1007/s13389-012-0027-1'>
+
+<front>
+<title>High-speed high-security signatures</title>
+<author fullname='Daniel J. Bernstein' surname='Bernstein' initials='D.' />
+<author fullname='Niels Duif' surname='Duif' initials='N.' />
+<author fullname='Tanja Lange' surname='Lange' initials='T.' />
+<author fullname='Peter Schwabe' surname='Schwabe' initials='P.'/>
+<author fullname='Bo-Yin Yang' surname='Yang' initials='B.'/>
+<date year='2011' month='September'/>
+<abstract>
+<t>This paper shows that a $390 mass-market quad-core 2.4GHz
+Intel Westmere (Xeon E5620) CPU can create 109000 signatures per
+second and verify 71000 signatures per second on an elliptic curve at a
+2128 security level. Public keys are 32 bytes, and signatures are 64 bytes.
+These performance figures include strong defenses against software side-
+channel attacks: there is no data flow from secret keys to array indices,
+and there is no data flow from secret keys to branch conditions.</t>
+</abstract>
+</front>
+
+<seriesInfo name='Journal of Cryptographic Engineering'
+ value='Volume 2, Issue 2, pp. 77-89' />
+</reference>
diff --git a/misc/id/common/reference.RFC.2119.xml b/misc/id/common/reference.RFC.2119.xml
new file mode 100644
index 0000000..3c41c07
--- /dev/null
+++ b/misc/id/common/reference.RFC.2119.xml
@@ -0,0 +1,44 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC2119'>
+
+<front>
+<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
+<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
+<organization>Harvard University</organization>
+<address>
+<postal>
+<street>1350 Mass. Ave.</street>
+<street>Cambridge</street>
+<street>MA 02138</street></postal>
+<phone>- +1 617 495 3864</phone>
+<email>sob at harvard.edu</email></address></author>
+<date year='1997' month='March' />
+<area>General</area>
+<keyword>keyword</keyword>
+<abstract>
+<t>
+ In many standards track documents several words are used to signify
+ the requirements in the specification. These words are often
+ capitalized. This document defines these words as they should be
+ interpreted in IETF documents. Authors who follow these guidelines
+ should incorporate this phrase near the beginning of their document:
+
+<list>
+<t>
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
+ NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ RFC 2119.
+</t></list></t>
+<t>
+ Note that the force of these words is modified by the requirement
+ level of the document in which they are used.
+</t></abstract></front>
+
+<seriesInfo name='BCP' value='14' />
+<seriesInfo name='RFC' value='2119' />
+<format type='TXT' octets='4723' target='http://www.rfc-editor.org/rfc/rfc2119.txt' />
+<format type='HTML' octets='17970' target='http://xml.resource.org/public/rfc/html/rfc2119.html' />
+<format type='XML' octets='5777' target='http://xml.resource.org/public/rfc/xml/rfc2119.xml' />
+</reference>
diff --git a/misc/id/common/reference.RFC.2434.xml b/misc/id/common/reference.RFC.2434.xml
new file mode 100644
index 0000000..02be9ea
--- /dev/null
+++ b/misc/id/common/reference.RFC.2434.xml
@@ -0,0 +1,58 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC2434'>
+
+<front>
+<title abbrev='Guidelines for IANA Considerations'>Guidelines for Writing an IANA Considerations Section in RFCs</title>
+<author initials='T.' surname='Narten' fullname='Thomas Narten'>
+<organization>IBM Corporation</organization>
+<address>
+<postal>
+<street>3039 Cornwallis Ave.</street>
+<street>PO Box 12195 - BRQA/502</street>
+<street>Research Triangle Park</street>
+<street>NC 27709-2195</street></postal>
+<phone>919-254-7798</phone>
+<email>narten at raleigh.ibm.com</email></address></author>
+<author initials='H.T.' surname='Alvestrand' fullname='Harald Tveit Alvestrand'>
+<organization>Maxware</organization>
+<address>
+<postal>
+<street>Pirsenteret</street>
+<street>N-7005 Trondheim</street>
+<country>Norway</country></postal>
+<phone>+47 73 54 57 97</phone>
+<email>Harald at Alvestrand.no</email></address></author>
+<date year='1998' month='October' />
+<area>General</area>
+<keyword>Internet Assigned Numbers Authority</keyword>
+<keyword>IANA</keyword>
+<abstract>
+<t>
+ Many protocols make use of identifiers consisting of constants and
+ other well-known values. Even after a protocol has been defined and
+ deployment has begun, new values may need to be assigned (e.g., for a
+ new option type in DHCP, or a new encryption or authentication
+ algorithm for IPSec). To insure that such quantities have consistent
+ values and interpretations in different implementations, their
+ assignment must be administered by a central authority. For IETF
+ protocols, that role is provided by the Internet Assigned Numbers
+ Authority (IANA).
+</t>
+<t>
+ In order for the IANA to manage a given name space prudently, it
+ needs guidelines describing the conditions under which new values can
+ be assigned. If the IANA is expected to play a role in the management
+ of a name space, the IANA must be given clear and concise
+ instructions describing that role. This document discusses issues
+ that should be considered in formulating a policy for assigning
+ values to a name space and provides guidelines to document authors on
+ the specific text that must be included in documents that place
+ demands on the IANA.
+</t></abstract></front>
+
+<seriesInfo name='BCP' value='26' />
+<seriesInfo name='RFC' value='2434' />
+<format type='TXT' octets='25092' target='http://www.rfc-editor.org/rfc/rfc2434.txt' />
+<format type='XML' octets='27060' target='http://xml.resource.org/public/rfc/xml/rfc2434.xml' />
+</reference>
diff --git a/misc/id/common/reference.RFC.4880.xml b/misc/id/common/reference.RFC.4880.xml
new file mode 100644
index 0000000..809cd97
--- /dev/null
+++ b/misc/id/common/reference.RFC.4880.xml
@@ -0,0 +1,23 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC4880'>
+
+<front>
+<title>OpenPGP Message Format</title>
+<author initials='J.' surname='Callas' fullname='J. Callas'>
+<organization /></author>
+<author initials='L.' surname='Donnerhacke' fullname='L. Donnerhacke'>
+<organization /></author>
+<author initials='H.' surname='Finney' fullname='H. Finney'>
+<organization /></author>
+<author initials='D.' surname='Shaw' fullname='D. Shaw'>
+<organization /></author>
+<author initials='R.' surname='Thayer' fullname='R. Thayer'>
+<organization /></author>
+<date year='2007' month='November' />
+<abstract>
+<t>This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws.</t><t> OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. [STANDARDS-TRACK]</t></abstract></front>
+
+<seriesInfo name='RFC' value='4880' />
+<format type='TXT' octets='203706' target='http://www.rfc-editor.org/rfc/rfc4880.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.5226.xml b/misc/id/common/reference.RFC.5226.xml
new file mode 100644
index 0000000..0af19ad
--- /dev/null
+++ b/misc/id/common/reference.RFC.5226.xml
@@ -0,0 +1,18 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC5226'>
+
+<front>
+<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
+<author initials='T.' surname='Narten' fullname='T. Narten'>
+<organization /></author>
+<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
+<organization /></author>
+<date year='2008' month='May' />
+<abstract>
+<t>Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract></front>
+
+<seriesInfo name='BCP' value='26' />
+<seriesInfo name='RFC' value='5226' />
+<format type='TXT' octets='66160' target='http://www.rfc-editor.org/rfc/rfc5226.txt' />
+</reference>
diff --git a/misc/id/common/reference.RFC.6637.xml b/misc/id/common/reference.RFC.6637.xml
new file mode 100644
index 0000000..d7e8394
--- /dev/null
+++ b/misc/id/common/reference.RFC.6637.xml
@@ -0,0 +1,15 @@
+<?xml version='1.0' encoding='UTF-8'?>
+
+<reference anchor='RFC6637'>
+
+<front>
+<title>Elliptic Curve Cryptography (ECC) in OpenPGP</title>
+<author initials='A.' surname='Jivsov' fullname='A. Jivsov'>
+<organization /></author>
+<date year='2012' month='June' />
+<abstract>
+<t>This document defines an Elliptic Curve Cryptography extension to the OpenPGP public key format and specifies three Elliptic Curves that enjoy broad support by other standards, including standards published by the US National Institute of Standards and Technology. The document specifies the conventions for interoperability between compliant OpenPGP implementations that make use of this extension and these Elliptic Curves. [STANDARDS-TRACK]</t></abstract></front>
+
+<seriesInfo name='RFC' value='6637' />
+<format type='TXT' octets='31532' target='http://www.rfc-editor.org/rfc/rfc6637.txt' />
+</reference>
diff --git a/misc/id/eddsa-for-openpgp/abstract.mkd b/misc/id/eddsa-for-openpgp/abstract.mkd
new file mode 100644
index 0000000..570f428
--- /dev/null
+++ b/misc/id/eddsa-for-openpgp/abstract.mkd
@@ -0,0 +1,2 @@
+This specification extends OpenPGP with the EdDSA public key algorithm
+and describes the use of curve Ed25519.
diff --git a/misc/id/eddsa-for-openpgp/back.mkd b/misc/id/eddsa-for-openpgp/back.mkd
new file mode 100644
index 0000000..420f564
--- /dev/null
+++ b/misc/id/eddsa-for-openpgp/back.mkd
@@ -0,0 +1,60 @@
+# Test vectors
+
+For help implementing this specification a non-normative example is
+given. This example assumes that the algorithm id for EdDSA will
+be 22.
+
+
+## Sample key
+
+The secret key used for this example is:
+
+ D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2
+
+Note that this is the raw secret key used as input to the EdDSA
+signing operation. The key was created on 2014-08-19 14:28:27 and
+thus the fingerprint of the OpenPGP key is:
+
+ C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A
+
+The algorithm specific input parameters without the MPI length headers
+are:
+
+ oid: 2b06010401da470f01
+
+ q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406
+
+The entire public key packet is thus:
+
+ 98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47
+ 0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19
+ 79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e
+ 43 ee 3b 24 06
+
+## Sample signature
+
+The signature is created using the sample key over the input data
+"OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash
+function is:
+
+ m: 4f70656e504750040016080006050255f95f9504ff0000000c
+
+Using the SHA-256 hash algorithm yields the digest:
+
+ d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280
+
+Which is fed into the EdDSA signature function and yields this signature:
+
+ r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366
+
+ s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404
+
+Note the MPI encoding rules require that the value of S needs to be
+prefixed with a 0x00 octet. The entire signature packet is thus:
+
+ 88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a
+ 09 10 8c fd e1 21 97 96 5a 9a f6 22 01 00 56 f9
+ 0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2
+ 7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00
+ d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e
+ a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04
diff --git a/misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-00.txt b/misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-00.txt
new file mode 100644
index 0000000..4b6c8a6
--- /dev/null
+++ b/misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-00.txt
@@ -0,0 +1,392 @@
+
+
+
+
+Network Working Group W. Koch
+Internet-Draft g10 Code
+Intended status: Standards Track August 19, 2014
+Expires: February 20, 2015
+
+
+ EdDSA for OpenPGP
+ draft-koch-eddsa-for-openpgp-00
+
+Abstract
+
+ This specification extends OpenPGP with the EdDSA public key
+ algorithm and describes the use of curve Ed25519.
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on February 20, 2015.
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+Koch Expires February 20, 2015 [Page 1]
+
+Internet-Draft EdDSA for OpenPGP August 2014
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Supported Curves . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Point Format . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Encoding of Public and Private Keys . . . . . . . . . . . . . 3
+ 5. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Curve OID . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . 5
+ Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 6
+ A.1. Sample key . . . . . . . . . . . . . . . . . . . . . . . 6
+ A.2. Sample signature . . . . . . . . . . . . . . . . . . . . 6
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+1. Introduction
+
+ The OpenPGP specification in [RFC4880] defines the RSA, Elgamal, and
+ DSA public key algorithms. [RFC6637] adds support for Elliptic Curve
+ Cryptography and specifies the ECDSA and ECDH algorithms. Due to
+ patent reasons no point compression was defined.
+
+ This document specifies how to use the EdDSA public key signature
+ algorithm [ED25519] with the OpenPGP standard. It defines a new
+ signature algorithm named EdDSA and specifies how to use the Ed25519
+ curve with EdDSA. This algorithm uses a custom point compression
+ method.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. Supported Curves
+
+ This document references the Curve "Ed25519" which is the Edwards
+ form of "Curve25519" and specified in the same paper as the "EdDSA"
+ algorithm ([ED25519]).
+
+ Other curves may be used by using a specific OID for the curve and
+ its EdDSA parameters.
+
+ The following public key algorithm IDs are added to expand section
+ 9.1 of [RFC4880], "Public-Key Algorithms":
+
+
+
+
+
+
+Koch Expires February 20, 2015 [Page 2]
+
+Internet-Draft EdDSA for OpenPGP August 2014
+
+
+ +-------+-----------------------------+
+ | ID | Description of Algorithm |
+ +-------+-----------------------------+
+ | TBD1 | EdDSA public key algorithm |
+ +-------+-----------------------------+
+
+ Compliant applications MUST support EdDSA with the curve Ed25519.
+ Applications MAY support other curves as long as a dedicated OID for
+ that curve is used.
+
+3. Point Format
+
+ The EdDSA algorithm defines a specific point compression format. To
+ indicate the use of this compression format and to make sure that the
+ key can be represented in the Multiprecision Internet (MPI) format of
+ [RFC4880] the octet string specifying the point is prefixed with the
+ octet 0x40. This encoding is an extension of the encoding given in
+ [RFC6637] which uses 0x04 to indicate an uncompressed point.
+
+ For example, the length of a public key for the curve Ed25519 is 263
+ bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the
+ native value of the public key.
+
+4. Encoding of Public and Private Keys
+
+ The following algorithm specific packets are added to Section 5.5.2
+ of [RFC4880], "Public-Key Packet Formats", to support EdDSA.
+
+ Algorithm-Specific Fields for EdDSA keys:
+
+ o a variable length field containing a curve OID, formatted as
+ follows:
+
+ * a one-octet size of the following field; values 0 and 0xFF are
+ reserved for future extensions,
+
+ * octets representing a curve OID, defined in Section 6.
+
+ o MPI of an EC point representing a public key Q as described under
+ Point Format above.
+
+ The following algorithm specific packets are added to Section 5.5.3
+ of [RFC4880], "Secret-Key Packet Formats", to support EdDSA.
+
+ Algorithm-Specific Fields for EdDSA keys:
+
+ o an MPI of an integer representing the secret key, which is a
+ scalar of the public EC point.
+
+
+
+Koch Expires February 20, 2015 [Page 3]
+
+Internet-Draft EdDSA for OpenPGP August 2014
+
+
+ The version 4 packet format MUST be used.
+
+5. Message Encoding
+
+ Section 5.2.3 of [RFC4880], "Version 4 Signature Packet Format"
+ specifies formats. To support EdDSA no change is required, the MPIs
+ representing the R and S value are encoded as MPIs in the same way as
+ done for the DSA and ECDSA algorithms; in particular the Algorithm-
+ Specific Fields for an EdDSA signature are:
+
+ - MPI of EdDSA value r.
+
+ - MPI of EdDSA value s.
+
+ Note that the compressed version of R and S as specified for EdDSA
+ ([ED25519]) is used.
+
+ The version 3 signature format MUST NOT be used with EdDSA.
+
+ Although that algorithm allows arbitrary data as input, its use with
+ OpenPGP requires that a digest of the message is used as input. See
+ section 5.2.4 of [RFC4880], "Computing Signatures" for details.
+ Truncation of the resulting digest is never applied; the resulting
+ digest value is used verbatim as input to the EdDSA algorithm.
+
+6. Curve OID
+
+ The EdDSA key parameter curve OID is an array of octets that defines
+ a named curve. The table below specifies the exact sequence of bytes
+ for each named curve referenced in this document:
+
+ +------------------------+------+------------------------+----------+
+ | OID | Len | Encoding in hex format | Name |
+ +------------------------+------+------------------------+----------+
+ | 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 |
+ | | | 0F 01 | |
+ +------------------------+------+------------------------+----------+
+
+ See [RFC6637] for a description of the OID encoding given in the
+ second and third columns.
+
+7. Security Considerations
+
+ The security considerations of [RFC4880] apply accordingly.
+
+ The use of EdDSA with the Ed25519 curve is believed to be as strong
+ as other curves of the same size. However, a proper implementation
+ of this algorithm avoids most security problems due to wrong usage.
+
+
+
+Koch Expires February 20, 2015 [Page 4]
+
+Internet-Draft EdDSA for OpenPGP August 2014
+
+
+ The algorithm does not require a unique random number for each
+ signature created by the same key.
+
+8. IANA Considerations
+
+ IANA is requested to assign an algorithm number from the OpenPGP
+ Public-Key Algorithms range, or the "namespace" in the terminology of
+ [RFC5226], that was created by [RFC4880]. See section 2.
+
+ +-------+-----------------------------+------------+
+ | ID | Algorithm | Reference |
+ +-------+-----------------------------+------------+
+ | TBD1 | EdDSA public key algorithm | This doc |
+ +-------+-----------------------------+------------+
+
+ [Notes to RFC-Editor: Please remove the table above on publication.
+ It is desirable not to reuse old or reserved algorithms because some
+ existing tools might print a wrong description. A higher number is
+ also an indication for a newer algorithm. As of now 22 is the next
+ free number.]
+
+9. Acknowledgments
+
+ The author would like to acknowledge the help of the individuals who
+ kindly voiced their opinions on the IETF OpenPGP and GnuPG mailing
+ lists, in particular, the help of Andrey Jivsov, Jon Callas, and
+ NIIBE Yutaka.
+
+10. Normative References
+
+ [ED25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B.
+ Yang, "High-speed high-security signatures", Journal of
+ Cryptographic Engineering Volume 2, Issue 2, pp. 77-89,
+ September 2011,
+ <http://dx.doi.org/10.1007/s13389-012-0027-1>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in
+ OpenPGP", RFC 6637, June 2012.
+
+
+
+Koch Expires February 20, 2015 [Page 5]
+
+Internet-Draft EdDSA for OpenPGP August 2014
+
+
+Appendix A. Test vectors
+
+ To help implementing this specification a non-normative example is
+ given. This example assumes that the algorithm id for EdDSA will be
+ 22.
+
+A.1. Sample key
+
+ The secret key used for this example is:
+
+ D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2
+
+ Note that this is the raw secret key as used as input to the EdDSA
+ signing operation. The key was created on 2014-08-19 14:28:27 and
+ thus the fingerprint of the OpenPGP key is:
+
+ C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A
+
+ The algorithm specific input parameters without the MPI length
+ headers are:
+
+ oid: 2b06010401da470f01
+
+ q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406
+
+ The entire public key packet is thus
+
+ 98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47
+ 0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19
+ 79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e
+ 43 ee 3b 24 06
+
+A.2. Sample signature
+
+ The signature is created using the sample key over the input data
+ "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash
+ function is
+
+ m: 4f70656e504750040016080006050255f95f9504ff0000000c
+
+ using the SHA-256 hash algorithm yields this digest
+
+ d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280
+
+ which is fed into the EdDSA signature function and yields this
+ signature:
+
+ r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366
+
+
+
+Koch Expires February 20, 2015 [Page 6]
+
+Internet-Draft EdDSA for OpenPGP August 2014
+
+
+ s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404
+
+ Note that the MPI encoding rules require that the value of S needs to
+ be prefixed with a 0x00 octet. The entire signature packet is thus
+
+ 88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a
+ 09 10 8c fd e1 21 97 96 5a 9a f6 22 01 00 56 f9
+ 0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2
+ 7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00
+ d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e
+ a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04
+
+Author's Address
+
+ Werner Koch
+ g10 Code
+
+ Email: wk at gnupg.org
+ URI: https://g10code.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires February 20, 2015 [Page 7]
diff --git a/misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-01.txt b/misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-01.txt
new file mode 100644
index 0000000..4a690eb
--- /dev/null
+++ b/misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-01.txt
@@ -0,0 +1,392 @@
+
+
+
+
+Network Working Group W. Koch
+Internet-Draft g10 Code
+Updates: 4880 (if approved) September 8, 2014
+Intended status: Informational
+Expires: March 12, 2015
+
+
+ EdDSA for OpenPGP
+ draft-koch-eddsa-for-openpgp-01
+
+Abstract
+
+ This specification extends OpenPGP with the EdDSA public key
+ algorithm and describes the use of curve Ed25519.
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on March 12, 2015.
+
+Copyright Notice
+
+ Copyright (c) 2014 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+Koch Expires March 12, 2015 [Page 1]
+
+Internet-Draft EdDSA for OpenPGP September 2014
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Supported Curves . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Point Format . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Encoding of Public and Private Keys . . . . . . . . . . . . . 3
+ 5. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Curve OID . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . 5
+ Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 6
+ A.1. Sample key . . . . . . . . . . . . . . . . . . . . . . . 6
+ A.2. Sample signature . . . . . . . . . . . . . . . . . . . . 6
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+1. Introduction
+
+ The OpenPGP specification in [RFC4880] defines the RSA, Elgamal, and
+ DSA public key algorithms. [RFC6637] adds support for Elliptic Curve
+ Cryptography and specifies the ECDSA and ECDH algorithms. Due to
+ patent reasons no point compression was defined.
+
+ This document specifies how to use the EdDSA public key signature
+ algorithm [ED25519] with the OpenPGP standard. It defines a new
+ signature algorithm named EdDSA and specifies how to use the Ed25519
+ curve with EdDSA. This algorithm uses a custom point compression
+ method. There are three main advantages of the EdDSA algorithm: It
+ does not require the use of a unique random number for each
+ signature, there are no padding or truncation issues as with ECDSA,
+ and it is more resilient to side-channel attacks.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. Supported Curves
+
+ This document references the Curve "Ed25519" which is the Edwards
+ form of "Curve25519" and specified in the same paper as the "EdDSA"
+ algorithm ([ED25519]).
+
+ Other curves may be used by using a specific OID for the curve and
+ its EdDSA parameters.
+
+ The following public key algorithm IDs are added to expand section
+ 9.1 of [RFC4880], "Public-Key Algorithms":
+
+
+
+Koch Expires March 12, 2015 [Page 2]
+
+Internet-Draft EdDSA for OpenPGP September 2014
+
+
+ +-------+-----------------------------+
+ | ID | Description of Algorithm |
+ +-------+-----------------------------+
+ | TBD1 | EdDSA public key algorithm |
+ +-------+-----------------------------+
+
+ Compliant applications MUST support EdDSA with the curve Ed25519.
+ Applications MAY support other curves as long as a dedicated OID for
+ using that curve with EdDSA is used.
+
+3. Point Format
+
+ The EdDSA algorithm defines a specific point compression format. To
+ indicate the use of this compression format and to make sure that the
+ key can be represented in the Multiprecision Internet (MPI) format of
+ [RFC4880] the octet string specifying the point is prefixed with the
+ octet 0x40. This encoding is an extension of the encoding given in
+ [RFC6637] which uses 0x04 to indicate an uncompressed point.
+
+ For example, the length of a public key for the curve Ed25519 is 263
+ bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the
+ native value of the public key.
+
+4. Encoding of Public and Private Keys
+
+ The following algorithm specific packets are added to Section 5.5.2
+ of [RFC4880], "Public-Key Packet Formats", to support EdDSA.
+
+ Algorithm-Specific Fields for EdDSA keys:
+
+ o a variable length field containing a curve OID, formatted as
+ follows:
+
+ * a one-octet size of the following field; values 0 and 0xFF are
+ reserved for future extensions,
+
+ * octets representing a curve OID, defined in Section 6.
+
+ o MPI of an EC point representing a public key Q as described under
+ Point Format above.
+
+ The following algorithm specific packets are added to Section 5.5.3
+ of [RFC4880], "Secret-Key Packet Formats", to support EdDSA.
+
+ Algorithm-Specific Fields for EdDSA keys:
+
+ o an MPI of an integer representing the secret key, which is a
+ scalar of the public EC point.
+
+
+
+Koch Expires March 12, 2015 [Page 3]
+
+Internet-Draft EdDSA for OpenPGP September 2014
+
+
+ The version 4 packet format MUST be used.
+
+5. Message Encoding
+
+ Section 5.2.3 of [RFC4880], "Version 4 Signature Packet Format"
+ specifies formats. To support EdDSA no change is required, the MPIs
+ representing the R and S value are encoded as MPIs in the same way as
+ done for the DSA and ECDSA algorithms; in particular the Algorithm-
+ Specific Fields for an EdDSA signature are:
+
+ - MPI of EdDSA value r.
+
+ - MPI of EdDSA value s.
+
+ Note that the compressed version of R and S as specified for EdDSA
+ ([ED25519]) is used.
+
+ The version 3 signature format MUST NOT be used with EdDSA.
+
+ Although that algorithm allows arbitrary data as input, its use with
+ OpenPGP requires that a digest of the message is used as input. See
+ section 5.2.4 of [RFC4880], "Computing Signatures" for details.
+ Truncation of the resulting digest is never applied; the resulting
+ digest value is used verbatim as input to the EdDSA algorithm.
+
+6. Curve OID
+
+ The EdDSA key parameter curve OID is an array of octets that defines
+ a named curve. The table below specifies the exact sequence of bytes
+ for each named curve referenced in this document:
+
+ +------------------------+------+------------------------+----------+
+ | OID | Len | Encoding in hex format | Name |
+ +------------------------+------+------------------------+----------+
+ | 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 |
+ | | | 0F 01 | |
+ +------------------------+------+------------------------+----------+
+
+ See [RFC6637] for a description of the OID encoding given in the
+ second and third columns.
+
+7. Security Considerations
+
+ The security considerations of [RFC4880] apply accordingly.
+
+ Although technically possible the use of EdDSA with digest algorithms
+ weaker than SHA-256 (e.g. SHA-1) is not suggested.
+
+
+
+
+Koch Expires March 12, 2015 [Page 4]
+
+Internet-Draft EdDSA for OpenPGP September 2014
+
+
+8. IANA Considerations
+
+ IANA is requested to assign an algorithm number from the OpenPGP
+ Public-Key Algorithms range, or the "namespace" in the terminology of
+ [RFC5226], that was created by [RFC4880]. See section 2.
+
+ +-------+-----------------------------+------------+
+ | ID | Algorithm | Reference |
+ +-------+-----------------------------+------------+
+ | TBD1 | EdDSA public key algorithm | This doc |
+ +-------+-----------------------------+------------+
+
+ [Notes to RFC-Editor: Please remove the table above on publication.
+ It is desirable not to reuse old or reserved algorithms because some
+ existing tools might print a wrong description. A higher number is
+ also an indication for a newer algorithm. As of now 22 is the next
+ free number.]
+
+9. Acknowledgments
+
+ The author would like to acknowledge the help of the individuals who
+ kindly voiced their opinions on the IETF OpenPGP and GnuPG mailing
+ lists, in particular, the help of Andrey Jivsov, Jon Callas, and
+ NIIBE Yutaka.
+
+10. Normative References
+
+ [ED25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B.
+ Yang, "High-speed high-security signatures", Journal of
+ Cryptographic Engineering Volume 2, Issue 2, pp. 77-89,
+ September 2011,
+ <http://dx.doi.org/10.1007/s13389-012-0027-1>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in
+ OpenPGP", RFC 6637, June 2012.
+
+
+
+
+
+
+Koch Expires March 12, 2015 [Page 5]
+
+Internet-Draft EdDSA for OpenPGP September 2014
+
+
+Appendix A. Test vectors
+
+ To help implementing this specification a non-normative example is
+ given. This example assumes that the algorithm id for EdDSA will be
+ 22.
+
+A.1. Sample key
+
+ The secret key used for this example is:
+
+ D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2
+
+ Note that this is the raw secret key as used as input to the EdDSA
+ signing operation. The key was created on 2014-08-19 14:28:27 and
+ thus the fingerprint of the OpenPGP key is:
+
+ C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A
+
+ The algorithm specific input parameters without the MPI length
+ headers are:
+
+ oid: 2b06010401da470f01
+
+ q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406
+
+ The entire public key packet is thus
+
+ 98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47
+ 0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19
+ 79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e
+ 43 ee 3b 24 06
+
+A.2. Sample signature
+
+ The signature is created using the sample key over the input data
+ "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash
+ function is
+
+ m: 4f70656e504750040016080006050255f95f9504ff0000000c
+
+ using the SHA-256 hash algorithm yields this digest
+
+ d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280
+
+ which is fed into the EdDSA signature function and yields this
+ signature:
+
+ r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366
+
+
+
+Koch Expires March 12, 2015 [Page 6]
+
+Internet-Draft EdDSA for OpenPGP September 2014
+
+
+ s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404
+
+ Note that the MPI encoding rules require that the value of S needs to
+ be prefixed with a 0x00 octet. The entire signature packet is thus
+
+ 88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a
+ 09 10 8c fd e1 21 97 96 5a 9a f6 22 01 00 56 f9
+ 0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2
+ 7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00
+ d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e
+ a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04
+
+Author's Address
+
+ Werner Koch
+ g10 Code
+
+ Email: wk at gnupg.org
+ URI: https://g10code.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires March 12, 2015 [Page 7]
diff --git a/misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-02.txt b/misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-02.txt
new file mode 100644
index 0000000..8e23a71
--- /dev/null
+++ b/misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-02.txt
@@ -0,0 +1,392 @@
+
+
+
+
+Network Working Group W. Koch
+Internet-Draft g10 Code
+Updates: 4880 (if approved) March 4, 2015
+Intended status: Informational
+Expires: September 5, 2015
+
+
+ EdDSA for OpenPGP
+ draft-koch-eddsa-for-openpgp-02
+
+Abstract
+
+ This specification extends OpenPGP with the EdDSA public key
+ algorithm and describes the use of curve Ed25519.
+
+Status of This Memo
+
+ This Internet-Draft is submitted in full conformance with the
+ provisions of BCP 78 and BCP 79.
+
+ Internet-Drafts are working documents of the Internet Engineering
+ Task Force (IETF). Note that other groups may also distribute
+ working documents as Internet-Drafts. The list of current Internet-
+ Drafts is at http://datatracker.ietf.org/drafts/current/.
+
+ Internet-Drafts are draft documents valid for a maximum of six months
+ and may be updated, replaced, or obsoleted by other documents at any
+ time. It is inappropriate to use Internet-Drafts as reference
+ material or to cite them other than as "work in progress."
+
+ This Internet-Draft will expire on September 5, 2015.
+
+Copyright Notice
+
+ Copyright (c) 2015 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (http://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+Koch Expires September 5, 2015 [Page 1]
+
+Internet-Draft EdDSA for OpenPGP March 2015
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Supported Curves . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Point Format . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 4. Encoding of Public and Private Keys . . . . . . . . . . . . . 3
+ 5. Message Encoding . . . . . . . . . . . . . . . . . . . . . . 4
+ 6. Curve OID . . . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 4
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
+ 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
+ 10. Normative References . . . . . . . . . . . . . . . . . . . . 5
+ Appendix A. Test vectors . . . . . . . . . . . . . . . . . . . . 6
+ A.1. Sample key . . . . . . . . . . . . . . . . . . . . . . . 6
+ A.2. Sample signature . . . . . . . . . . . . . . . . . . . . 6
+ Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
+
+1. Introduction
+
+ The OpenPGP specification in [RFC4880] defines the RSA, Elgamal, and
+ DSA public key algorithms. [RFC6637] adds support for Elliptic Curve
+ Cryptography and specifies the ECDSA and ECDH algorithms. Due to
+ patent reasons no point compression was defined.
+
+ This document specifies how to use the EdDSA public key signature
+ algorithm [ED25519] with the OpenPGP standard. It defines a new
+ signature algorithm named EdDSA and specifies how to use the Ed25519
+ curve with EdDSA. This algorithm uses a custom point compression
+ method. There are three main advantages of the EdDSA algorithm: It
+ does not require the use of a unique random number for each
+ signature, there are no padding or truncation issues as with ECDSA,
+ and it is more resilient to side-channel attacks.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [RFC2119].
+
+2. Supported Curves
+
+ This document references the Curve "Ed25519" which is the Edwards
+ form of "Curve25519" and specified in the same paper as the "EdDSA"
+ algorithm ([ED25519]).
+
+ Other curves may be used by using a specific OID for the curve and
+ its EdDSA parameters.
+
+ The following public key algorithm IDs are added to expand section
+ 9.1 of [RFC4880], "Public-Key Algorithms":
+
+
+
+Koch Expires September 5, 2015 [Page 2]
+
+Internet-Draft EdDSA for OpenPGP March 2015
+
+
+ +-------+-----------------------------+
+ | ID | Description of Algorithm |
+ +-------+-----------------------------+
+ | TBD1 | EdDSA public key algorithm |
+ +-------+-----------------------------+
+
+ Compliant applications MUST support EdDSA with the curve Ed25519.
+ Applications MAY support other curves as long as a dedicated OID for
+ using that curve with EdDSA is used.
+
+3. Point Format
+
+ The EdDSA algorithm defines a specific point compression format. To
+ indicate the use of this compression format and to make sure that the
+ key can be represented in the Multiprecision Internet (MPI) format of
+ [RFC4880] the octet string specifying the point is prefixed with the
+ octet 0x40. This encoding is an extension of the encoding given in
+ [RFC6637] which uses 0x04 to indicate an uncompressed point.
+
+ For example, the length of a public key for the curve Ed25519 is 263
+ bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the
+ native value of the public key.
+
+4. Encoding of Public and Private Keys
+
+ The following algorithm specific packets are added to Section 5.5.2
+ of [RFC4880], "Public-Key Packet Formats", to support EdDSA.
+
+ Algorithm-Specific Fields for EdDSA keys:
+
+ o a variable length field containing a curve OID, formatted as
+ follows:
+
+ * a one-octet size of the following field; values 0 and 0xFF are
+ reserved for future extensions,
+
+ * octets representing a curve OID, defined in Section 6.
+
+ o MPI of an EC point representing a public key Q as described under
+ Point Format above.
+
+ The following algorithm specific packets are added to Section 5.5.3
+ of [RFC4880], "Secret-Key Packet Formats", to support EdDSA.
+
+ Algorithm-Specific Fields for EdDSA keys:
+
+ o an MPI of an integer representing the secret key, which is a
+ scalar of the public EC point.
+
+
+
+Koch Expires September 5, 2015 [Page 3]
+
+Internet-Draft EdDSA for OpenPGP March 2015
+
+
+ The version 4 packet format MUST be used.
+
+5. Message Encoding
+
+ Section 5.2.3 of [RFC4880], "Version 4 Signature Packet Format"
+ specifies formats. To support EdDSA no change is required, the MPIs
+ representing the R and S value are encoded as MPIs in the same way as
+ done for the DSA and ECDSA algorithms; in particular the Algorithm-
+ Specific Fields for an EdDSA signature are:
+
+ - MPI of EdDSA value r.
+
+ - MPI of EdDSA value s.
+
+ Note that the compressed version of R and S as specified for EdDSA
+ ([ED25519]) is used.
+
+ The version 3 signature format MUST NOT be used with EdDSA.
+
+ Although that algorithm allows arbitrary data as input, its use with
+ OpenPGP requires that a digest of the message is used as input. See
+ section 5.2.4 of [RFC4880], "Computing Signatures" for details.
+ Truncation of the resulting digest is never applied; the resulting
+ digest value is used verbatim as input to the EdDSA algorithm.
+
+6. Curve OID
+
+ The EdDSA key parameter curve OID is an array of octets that defines
+ a named curve. The table below specifies the exact sequence of bytes
+ for each named curve referenced in this document:
+
+ +------------------------+------+------------------------+----------+
+ | OID | Len | Encoding in hex format | Name |
+ +------------------------+------+------------------------+----------+
+ | 1.3.6.1.4.1.11591.15.1 | 9 | 2B 06 01 04 01 DA 47 | Ed25519 |
+ | | | 0F 01 | |
+ +------------------------+------+------------------------+----------+
+
+ See [RFC6637] for a description of the OID encoding given in the
+ second and third columns.
+
+7. Security Considerations
+
+ The security considerations of [RFC4880] apply accordingly.
+
+ Although technically possible the use of EdDSA with digest algorithms
+ weaker than SHA-256 (e.g. SHA-1) is not suggested.
+
+
+
+
+Koch Expires September 5, 2015 [Page 4]
+
+Internet-Draft EdDSA for OpenPGP March 2015
+
+
+8. IANA Considerations
+
+ IANA is requested to assign an algorithm number from the OpenPGP
+ Public-Key Algorithms range, or the "namespace" in the terminology of
+ [RFC5226], that was created by [RFC4880]. See section 2.
+
+ +-------+-----------------------------+------------+
+ | ID | Algorithm | Reference |
+ +-------+-----------------------------+------------+
+ | TBD1 | EdDSA public key algorithm | This doc |
+ +-------+-----------------------------+------------+
+
+ [Notes to RFC-Editor: Please remove the table above on publication.
+ It is desirable not to reuse old or reserved algorithms because some
+ existing tools might print a wrong description. A higher number is
+ also an indication for a newer algorithm. As of now 22 is the next
+ free number.]
+
+9. Acknowledgments
+
+ The author would like to acknowledge the help of the individuals who
+ kindly voiced their opinions on the IETF OpenPGP and GnuPG mailing
+ lists, in particular, the help of Andrey Jivsov, Jon Callas, and
+ NIIBE Yutaka.
+
+10. Normative References
+
+ [ED25519] Bernstein, D., Duif, N., Lange, T., Schwabe, P., and B.
+ Yang, "High-speed high-security signatures", Journal of
+ Cryptographic Engineering Volume 2, Issue 2, pp. 77-89,
+ September 2011,
+ <http://dx.doi.org/10.1007/s13389-012-0027-1>.
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
+ Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
+
+ [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
+ IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+ May 2008.
+
+ [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in
+ OpenPGP", RFC 6637, June 2012.
+
+
+
+
+
+
+Koch Expires September 5, 2015 [Page 5]
+
+Internet-Draft EdDSA for OpenPGP March 2015
+
+
+Appendix A. Test vectors
+
+ To help implementing this specification a non-normative example is
+ given. This example assumes that the algorithm id for EdDSA will be
+ 22.
+
+A.1. Sample key
+
+ The secret key used for this example is:
+
+ D: 1a8b1ff05ded48e18bf50166c664ab023ea70003d78d9e41f5758a91d850f8d2
+
+ Note that this is the raw secret key as used as input to the EdDSA
+ signing operation. The key was created on 2014-08-19 14:28:27 and
+ thus the fingerprint of the OpenPGP key is:
+
+ C959 BDBA FA32 A2F8 9A15 3B67 8CFD E121 9796 5A9A
+
+ The algorithm specific input parameters without the MPI length
+ headers are:
+
+ oid: 2b06010401da470f01
+
+ q: 403f098994bdd916ed4053197934e4a87c80733a1280d62f8010992e43ee3b2406
+
+ The entire public key packet is thus
+
+ 98 33 04 53 f3 5f 0b 16 09 2b 06 01 04 01 da 47
+ 0f 01 01 07 40 3f 09 89 94 bd d9 16 ed 40 53 19
+ 79 34 e4 a8 7c 80 73 3a 12 80 d6 2f 80 10 99 2e
+ 43 ee 3b 24 06
+
+A.2. Sample signature
+
+ The signature is created using the sample key over the input data
+ "OpenPGP" on 2015-09-16 12:24:53 and thus the input to the hash
+ function is
+
+ m: 4f70656e504750040016080006050255f95f9504ff0000000c
+
+ using the SHA-256 hash algorithm yields this digest
+
+ d: f6220a3f757814f4c2176ffbb68b00249cd4ccdc059c4b34ad871f30b1740280
+
+ which is fed into the EdDSA signature function and yields this
+ signature:
+
+ r: 56f90cca98e2102637bd983fdb16c131dfd27ed82bf4dde5606e0d756aed3366
+
+
+
+Koch Expires September 5, 2015 [Page 6]
+
+Internet-Draft EdDSA for OpenPGP March 2015
+
+
+ s: d09c4fa11527f038e0f57f2201d82f2ea2c9033265fa6ceb489e854bae61b404
+
+ Note that the MPI encoding rules require that the value of S needs to
+ be prefixed with a 0x00 octet. The entire signature packet is thus
+
+ 88 5e 04 00 16 08 00 06 05 02 55 f9 5f 95 00 0a
+ 09 10 8c fd e1 21 97 96 5a 9a f6 22 01 00 56 f9
+ 0c ca 98 e2 10 26 37 bd 98 3f db 16 c1 31 df d2
+ 7e d8 2b f4 dd e5 60 6e 0d 75 6a ed 33 66 01 00
+ d0 9c 4f a1 15 27 f0 38 e0 f5 7f 22 01 d8 2f 2e
+ a2 c9 03 32 65 fa 6c eb 48 9e 85 4b ae 61 b4 04
+
+Author's Address
+
+ Werner Koch
+ g10 Code
+
+ Email: wk at gnupg.org
+ URI: https://g10code.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koch Expires September 5, 2015 [Page 7]
diff --git a/misc/id/eddsa-for-openpgp/middle.mkd b/misc/id/eddsa-for-openpgp/middle.mkd
new file mode 100644
index 0000000..9e2de3f
--- /dev/null
+++ b/misc/id/eddsa-for-openpgp/middle.mkd
@@ -0,0 +1,152 @@
+# Introduction
+
+The OpenPGP specification in [](#RFC4880) defines the RSA, Elgamal,
+and DSA public key algorithms. [](#RFC6637) adds support for
+Elliptic Curve Cryptography and specifies the ECDSA and ECDH
+algorithms. Due to patent reasons no point compression was defined.
+
+This document specifies how to use the EdDSA public key signature
+algorithm [](#ED25519) with the OpenPGP standard. It defines a new
+signature algorithm named EdDSA and specifies how to use the Ed25519
+curve with EdDSA. This algorithm uses a custom point compression
+method. There are three main advantages of the EdDSA algorithm: It
+does not require the use of a unique random number for each signature,
+there are no padding or truncation issues as with ECDSA, and it is
+more resilient to side-channel attacks.
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in [](#RFC2119).
+
+
+# Supported Curves
+
+This document references the Curve "Ed25519" which is the Edwards form
+of "Curve25519" and specified in the same paper as the "EdDSA"
+algorithm ([](#ED25519)).
+
+Other curves may be used by using a specific OID for the curve and its
+EdDSA parameters.
+
+The following public key algorithm IDs are added to expand section 9.1
+of [](#RFC4880), "Public-Key Algorithms":
+
+ ID Description of Algorithm
+ -- --------------------------
+ TBD1 EdDSA public key algorithm
+
+Compliant applications MUST support EdDSA with the curve Ed25519.
+Applications MAY support other curves as long as a dedicated OID for
+using that curve with EdDSA is used.
+
+# Point Format
+
+The EdDSA algorithm defines a specific point compression format. To
+indicate the use of this compression format and to make sure that the
+key can be represented in the Multiprecision Integer (MPI) format of
+[](#RFC4880) the octet string specifying the point is prefixed with
+the octet 0x40. This encoding is an extension of the encoding given
+in [](#RFC6637) which uses 0x04 to indicate an uncompressed point.
+
+For example, the length of a public key for the curve Ed25519 is 263
+bit: 7 bit to represent the 0x40 prefix octet and 32 octets for the
+native value of the public key.
+
+# Encoding of Public and Private Keys
+
+The following algorithm specific packets are added to Section 5.5.2
+of [](#RFC4880), "Public-Key Packet Formats", to support EdDSA.
+
+Algorithm-Specific Fields for EdDSA keys:
+
+- a variable length field containing a curve OID, formatted as
+ follows:
+
+ - a one-octet size of the following field; values 0 and 0xFF are
+ reserved for future extensions,
+
+ - octets representing a curve OID, defined in Section 6.
+
+- MPI of an EC point representing a public key Q as described under
+ Point Format above.
+
+The following algorithm specific packets are added to Section 5.5.3
+of [](#RFC4880), "Secret-Key Packet Formats", to support EdDSA.
+
+Algorithm-Specific Fields for EdDSA keys:
+
+- an MPI of an integer representing the secret key, which is a
+ scalar of the public EC point.
+
+The version 4 packet format MUST be used.
+
+
+# Message Encoding
+
+Section 5.2.3 of [](#RFC4880), "Version 4 Signature Packet Format"
+specifies formats. To support EdDSA no change is required, the MPIs
+representing the R and S value are encoded as MPIs in the same way as
+done for the DSA and ECDSA algorithms; in particular the
+Algorithm-Specific Fields for an EdDSA signature are:
+
+ - MPI of EdDSA value r.
+
+ - MPI of EdDSA value s.
+
+Note that the compressed version of R and S as specified for EdDSA
+([](#ED25519)) is used.
+
+The version 3 signature format MUST NOT be used with EdDSA.
+
+Although that algorithm allows arbitrary data as input, its use with
+OpenPGP requires that a digest of the message is used as input. See
+section 5.2.4 of [](#RFC4880), "Computing Signatures" for details.
+Truncation of the resulting digest is never applied; the resulting
+digest value is used verbatim as input to the EdDSA algorithm.
+
+
+# Curve OID
+
+The EdDSA key parameter curve OID is an array of octets that defines a
+named curve. The table below specifies the exact sequence of bytes
+for each named curve referenced in this document:
+
+ OID Len Encoding in hex format Name
+ ---------------------- --- -------------------------- -------
+ 1.3.6.1.4.1.11591.15.1 9 2B 06 01 04 01 DA 47 0F 01 Ed25519
+
+See [](#RFC6637) for a description of the OID encoding given in the
+second and third columns.
+
+
+# Security Considerations
+
+The security considerations of [](#RFC4880) apply accordingly.
+
+Although technically possible the use of EdDSA with digest algorithms
+weaker than SHA-256 (e.g. SHA-1) is not suggested.
+
+
+# IANA Considerations
+
+IANA is requested to assign an algorithm number from the OpenPGP
+Public-Key Algorithms range, or the "namespace" in the terminology of
+[](#RFC5226), that was created by [](#RFC4880). See section 2.
+
+ ID Algorithm Reference
+ -- -------------------------- ---------
+ TBD1 EdDSA public key algorithm This doc
+
+ [Notes to RFC-Editor: Please remove the table above on publication.
+ It is desirable not to reuse old or reserved algorithms because
+ some existing tools might print a wrong description. A higher
+ number is also an indication for a newer algorithm. As of now
+ 22 is the next free number.]
+
+
+# Acknowledgments
+
+The author would like to acknowledge the help of the individuals who
+kindly voiced their opinions on the IETF OpenPGP and GnuPG mailing
+lists, in particular, the help of Andrey Jivsov, Jon Callas, and NIIBE
+Yutaka.
diff --git a/misc/id/eddsa-for-openpgp/template.xml b/misc/id/eddsa-for-openpgp/template.xml
new file mode 100644
index 0000000..85bb532
--- /dev/null
+++ b/misc/id/eddsa-for-openpgp/template.xml
@@ -0,0 +1,57 @@
+<?xml version="1.0" ?>
+<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' [
+ <!ENTITY pandocAbstract PUBLIC '' 'abstract.xml'>
+ <!ENTITY pandocMiddle PUBLIC '' 'middle.xml'>
+ <!ENTITY pandocBack PUBLIC '' 'back.xml'>
+ <!ENTITY rfc.2119 PUBLIC '' '../common/reference.RFC.2119.xml'>
+ <!ENTITY rfc.2434 PUBLIC '' '../common/reference.RFC.2434.xml'>
+ <!ENTITY rfc.4880 PUBLIC '' '../common/reference.RFC.4880.xml'>
+ <!ENTITY rfc.5226 PUBLIC '' '../common/reference.RFC.5226.xml'>
+ <!ENTITY rfc.6637 PUBLIC '' '../common/reference.RFC.6637.xml'>
+ <!ENTITY ed25519 PUBLIC '' '../common/reference.ED25519.xml'>
+]>
+<rfc ipr="trust200902" category="info" updates="4880"
+ docName="draft-koch-eddsa-for-openpgp-03">
+
+<?rfc toc="yes"?>
+<?rfc symrefs="yes"?>
+<?rfc sortrefs="yes"?>
+<?rfc subcompact="no"?>
+<?rfc compact="yes"?>
+<?rfc comments="yes"?>
+
+
+ <front>
+ <title>EdDSA for OpenPGP</title>
+ <author initials="W." surname="Koch"
+ fullname="Werner Koch">
+ <organization>g10 Code</organization>
+ <address>
+ <email>wk at gnupg.org</email>
+ <uri>https://g10code.com</uri>
+ </address>
+ </author>
+
+ <date month="March" year="2015" />
+ <area>Security</area>
+
+ <abstract>
+ &pandocAbstract;
+ </abstract>
+ </front>
+
+ <middle>
+ &pandocMiddle;
+ </middle>
+
+ <back>
+ <references title="Normative References">
+ &ed25519;
+ &rfc.4880;
+ &rfc.6637;
+ &rfc.5226;
+ &rfc.2119;
+ </references>
+ &pandocBack;
+ </back>
+</rfc>
-----------------------------------------------------------------------
Summary of changes:
.gitignore | 1 +
misc/id/common/reference.ED25519.xml | 27 ++
misc/id/common/reference.RFC.2119.xml | 44 +++
misc/id/common/reference.RFC.2434.xml | 58 +++
misc/id/common/reference.RFC.4880.xml | 23 ++
misc/id/common/reference.RFC.5226.xml | 18 +
misc/id/common/reference.RFC.6637.xml | 15 +
misc/id/eddsa-for-openpgp/abstract.mkd | 2 +
misc/id/eddsa-for-openpgp/back.mkd | 60 ++++
.../draft-koch-eddsa-for-openpgp-00.txt | 392 +++++++++++++++++++++
.../draft-koch-eddsa-for-openpgp-01.txt | 392 +++++++++++++++++++++
.../draft-koch-eddsa-for-openpgp-02.txt | 392 +++++++++++++++++++++
misc/id/eddsa-for-openpgp/middle.mkd | 152 ++++++++
misc/id/eddsa-for-openpgp/template.xml | 57 +++
14 files changed, 1633 insertions(+)
create mode 100644 misc/id/common/reference.ED25519.xml
create mode 100644 misc/id/common/reference.RFC.2119.xml
create mode 100644 misc/id/common/reference.RFC.2434.xml
create mode 100644 misc/id/common/reference.RFC.4880.xml
create mode 100644 misc/id/common/reference.RFC.5226.xml
create mode 100644 misc/id/common/reference.RFC.6637.xml
create mode 100644 misc/id/eddsa-for-openpgp/abstract.mkd
create mode 100644 misc/id/eddsa-for-openpgp/back.mkd
create mode 100644 misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-00.txt
create mode 100644 misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-01.txt
create mode 100644 misc/id/eddsa-for-openpgp/draft-koch-eddsa-for-openpgp-02.txt
create mode 100644 misc/id/eddsa-for-openpgp/middle.mkd
create mode 100644 misc/id/eddsa-for-openpgp/template.xml
hooks/post-receive
--
The GnuPG website and other docs
http://git.gnupg.org
More information about the Gnupg-commits
mailing list