g10 Code

wk@gnupg.org https://g10code.com

Security This specification extends OpenPGP with the EdDSA public key algorithm and describes the use of curve Ed25519.

The OpenPGP specification in defines the RSA, Elgamal, and DSA public key algorithms. 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 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 .

This document references the Curve "Ed25519" which is the Edwards form of "Curve25519" and specified in the same paper as the "EdDSA" algorithm (). For the full specification see . 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 , "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.

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 the octet string specifying the point is prefixed with the octet 0x40. This encoding is an extension of the encoding given in 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.

The following algorithm specific packets are added to Section 5.5.2 of , "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 , "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.

Section 5.2.3 of , "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 () 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 , "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.

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 for a description of the OID encoding given in the second and third columns.

The security considerations of apply accordingly. Although technically possible the use of EdDSA with digest algorithms weaker than SHA-256 (e.g. SHA-1) is not suggested.

IANA is requested to assign an algorithm number from the OpenPGP Public-Key Algorithms range, or the "namespace" in the terminology of , that was created by . 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.]

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.

The elliptic curve signature scheme EdDSA and one instance of it called Ed25519 is described. An example implementation and test vectors are provided. 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] 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] 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. Harvard University

1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu

GeneralkeywordIn 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: 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. Note that the force of these words is modified by the requirement level of the document in which they are used. 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.

For help implementing this specification a non-normative example is given. This example assumes that the algorithm id for EdDSA (TBD1) will be 22.

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

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

This specification introduces the new flag byte 0x40 to indicate the point compression format. The value has been chosen so that the high bit is not cleared and thus to avoid accidental sign extension. Two other values might also be interesting for other ECC specifications:

Flag Description ---- ----------- 0x04 Standard flag for uncompression format 0x40 Native point format of the curve follows 0x41 Only X coordinate follows. 0x42 Only Y coordinate follows.

Fixed decription in the test vectors regarding an extra 0x00 byte. Small gramar fixes. Reference Josefsson's EdDSA I-D instead of the original paper.