Subject: [openpgp] rfc4880bis: Merged RFC-5581 and RFC-6637

From: Werner Koch <[email-masked]>
Date: Fri, 29 May 2015 21:40:51 +0200

Hi,

I merged the Camellia and the ECC For OpenPGP RFCs into 4880bis.  See

<http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg-doc.git;a=history;f=misc/id/rfc4880bis>

Below is a diff of the major changes related to RFC-6637.  I merged most
stuff except for parts which IMHO do not make sense: For example IANA
consideration to assign the algos and text explaining why ECC is a good
idea.

I am not sure whether the "Compatibility Profile" should go into 4880bis.
But it has been in 6637 and thus we should keep it for now.

Shalom-Salam,

   Werner

----------
    rfc4880bis: Merge with RFC-6637 (ECC for OpenPGP)
    
    This patch adds the new algorithm numbers for ECDH and ECDSA and marks
    them as MUST implement.  The bulk of RFC-6637 is added to the new
    sections Elliptic Curve Cryptography and Compatibility Profiles.  The
    remaining stuff goes into the Security Considerations.

diff --git a/misc/id/rfc4880bis/middle.mkd b/misc/id/rfc4880bis/middle.mkd
index 9ea7326..80c0a61 100644
--- a/misc/id/rfc4880bis/middle.mkd
+++ b/misc/id/rfc4880bis/middle.mkd
@@ -10,7 +10,8 @@ # {1} Introduction
 Message Format", which itself replaces RFC 1991, "PGP Message Exchange
 Formats" [](#RFC1991) [](#RFC2440).
 
-This document obsoletes: RFC 5581 (Camellia cipher).
+This document obsoletes: RFC 5581 (Camellia cipher) and RFC 6637 (ECC
+for OpenPGP)

 ## {1.1} Terms
@@ -635,6 +636,13 @@ ## {5.1}  Public-Key Encrypted Session Key Packets (Tag 1)
 
       - MPI of Elgamal (Diffie-Hellman) value m * y**k mod p.
 
+    Algorithm-Specific Fields for ECDH encryption:
+
+      - MPI of an EC point representing an ephemeral public key.
+
+      - a one-octet size, followed by a symmetric key encoded using the
+        method described in [](#ec-dh-algorithm-ecdh).
+
 The value "m" in the above formulas is derived from the session key as
 follows.  First, the session key is prefixed with a one-octet algorithm
 identifier that specifies the symmetric encryption algorithm used to
@@ -830,11 +838,11 @@ ### {5.2.2} Version 3 Signature Packet Format
 
       * Multiprecision integer (MPI) of RSA signature value m**d mod n.
 
-    Algorithm-Specific Fields for DSA signatures:
+    Algorithm-Specific Fields for DSA and ECDSA signatures:
 
-      * MPI of DSA value r.
+      * MPI of DSA or ECDSA value r.
 
-      * MPI of DSA value s.
+      * MPI of DSA or ECDSA value s.
 
 The signature calculation is based on a hash of the signed data, as
 described above.  The details of the calculation are different for DSA
@@ -1798,6 +1806,49 @@ ### {5.5.2} Public-Key Packet Formats
 
       - MPI of Elgamal public key value y (= g**x mod p where x is secret).
 
+    Algorithm-Specific Fields for ECDSA 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,
+
+           - the octets representing a curve OID, defined in
+             section 11{FIXME};
+
+      - a MPI of an EC point representing a public key.
+
+    Algorithm-Specific Fields for ECDH 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,
+
+           - the octets representing a curve OID, defined in
+             Section 11{FIXME};
+
+      - a MPI of an EC point representing a public key;
+
+      - a variable-length field containing KDF parameters,
+        formatted as follows:
+
+           - a one-octet size of the following fields; values 0
+             and 0xff are reserved for future extensions;
+
+           - a one-octet value 1, reserved for future extensions;
+
+           - a one-octet hash function ID used with a KDF;
+
+           - a one-octet algorithm ID for the symmetric algorithm
+             used to wrap the symmetric key used for the message
+             encryption; see Section 8 for details.
+
+Observe that an ECDH public key is composed of the same sequence of
+fields that define an ECDSA key, plus the KDF parameters field.
+
 ### {5.5.3} Secret-Key Packet Formats
 
 The Secret-Key and Secret-Subkey packets contain all the data of the
@@ -1856,6 +1907,12 @@ ### {5.5.3} Secret-Key Packet Formats
 
       - MPI of Elgamal secret exponent x.
 
+    Algorithm-Specific Fields for ECDH or ECDSA secret keys:
+
+      - MPI of an integer representing the secret key, which is a
+        scalar of the public EC point.
+
+
 Secret MPI values can be encrypted using a passphrase.  If a string-
 to-key specifier is given, that describes the algorithm for converting
 the passphrase to a key, else a simple MD5 hash of the passphrase is
@@ -2693,20 +2750,54 @@ ## {9.1} Public-Key Algorithms
         3  RSA Sign-Only [](#HAC)
        16  Elgamal (Encrypt-Only) [](#ELGAMAL) [](#HAC)
        17  DSA (Digital Signature Algorithm) [](#FIPS186) [](#HAC)
-       18  Reserved for Elliptic Curve
-       19  Reserved for ECDSA
+       18  ECDH public key algorithm
+       19  ECDSA public key algorithm [](#FIPS186-3)
        20  Reserved (formerly Elgamal Encrypt or Sign)
        21  Reserved for Diffie-Hellman
                       (X9.42, as defined for IETF-S/MIME)
  100--110  Private/Experimental algorithm
 
-Implementations MUST implement DSA for signatures, and Elgamal for
+Implementations MUST implement DSA and ECDSA for signatures, and
+Elgamal and ECDH for
 encryption.  Implementations SHOULD implement RSA keys (1).  RSA
 Encrypt-Only (2) and RSA Sign-Only are deprecated and SHOULD NOT be
-generated, but may be interpreted.  See Section 13.5.  See Section 13.8
-for notes on Elliptic Curve (18), ECDSA (19), Elgamal Encrypt or Sign
-(20), and X9.42 (21).  Implementations MAY implement any other
-algorithm.
+generated, but may be interpreted.  See Section 13.5.
+See Section 13.8 for notes Elgamal Encrypt or Sign (20), and X9.42 (21).
+Implementations MAY implement any other algorithm.
+
+A compatible specification of ECDSA is given in [](#RFC6090) as "KT-I
+Signatures" and in [](#SEC1); ECDH is defined in [](#ec-dh-algorithm-ecdh)
+this document.
+
+## ECC Curve OID
+
+The parameter curve OID is an array of octets that define a named
+curve.  The table below specifies the exact sequence of bytes for each
+named curve referenced in this document:
+
+  ------------         --- -----------------------  -------------
+  ASN.1 Object         OID Curve OID bytes in       Curve name in
+  Identifier           len hexadecimal              [FIPS186-3]
+                           representation
+  ------------         --- -----------------------  -------------
+  1.2.840.10045.3.1.7   8  2A 86 48 CE 3D 03 01 07  NIST curve P-256
+
+  1.3.132.0.34          5  2B 81 04 00 22           NIST curve P-384
+
+  1.3.132.0.35          5  2B 81 04 00 23           NIST curve P-521
+  ------------------------------------------------------------------
+
+The sequence of octets in the third column is the result of applying
+the Distinguished Encoding Rules (DER) to the ASN.1 Object Identifier
+with subsequent truncation.  The truncation removes the two fields of
+encoded Object Identifier.  The first omitted field is one octet
+representing the Object Identifier tag, and the second omitted field
+is the length of the Object Identifier body.  For example, the
+complete ASN.1 DER encoding for the NIST P-256 curve OID is "06 08 2A
+86 48 CE 3D 03 01 07", from which the first entry in the table above
+is constructed by omitting the first two octets.  Only the truncated
+sequence of octets is the valid representation of a curve OID.
+
 
 ## {9.2} Symmetric-Key Algorithms
 
@@ -3186,6 +3277,201 @@ ## {12.2} Key IDs and Fingerprints
 same way as for a primary key, including the 0x99 as the first octet
 (even though this is not a valid packet ID for a public subkey).
 
+# Elliptic Curve Cryptography
+
+This section descripes algorithms and parameters used with Elliptic
+Curve Cryptography (ECC) keys.  A thorough introduction to ECC can be
+found in [](#KOBLITZ).
+
+## Supported ECC Curves
+
+This document references three named prime field curves, defined in
+[](#FIPS186-3) as "Curve P-256", "Curve P-384", and "Curve P-521".
+
+The named curves are referenced as a sequence of bytes in this
+document, called throughout, curve OID.  [](#ecc-curve-oid) describes
+in detail how this sequence of bytes is formed.
+
+## ECC Conversion Primitives
+
+This document only defines the uncompressed point format.  The point
+is encoded in the Multiprecision Integer (MPI) format.  The
+content of the MPI is the following:
+
+    B = 04 || x || y
+
+where x and y are coordinates of the point P = (x, y), each encoded in
+the big-endian format and zero-padded to the adjusted underlying field
+size.  The adjusted underlying field size is the underlying field size
+that is rounded up to the nearest 8-bit boundary.
+
+Therefore, the exact size of the MPI payload is 515 bits for "Curve
+P-256", 771 for "Curve P-384", and 1059 for "Curve P-521".
+
+Even though the zero point, also called the point at infinity, may
+occur as a result of arithmetic operations on points of an elliptic
+curve, it SHALL NOT appear in data structures defined in this
+document.
+
+This encoding is compatible with the definition given in [](#SEC1).
+
+If other conversion methods are defined in the future, a compliant
+application MUST NOT use a new format when in doubt that any recipient
+can support it.  Consider, for example, that while both the public key
+and the per-recipient ECDH data structure, respectively defined in
+Sections 9{FIXME} and 10{FIXME}, contain an encoded point field, the
+format changes to the field in Section 10{FIXME} only affect a given
+recipient of a given message.
+
+## Key Derivation Function
+
+A key derivation function (KDF) is necessary to implement the EC
+encryption.  The Concatenation Key Derivation Function (Approved
+Alternative 1) [](#SP800-56A) with the KDF hash function that is
+SHA2-256 [](#FIPS180-3) or stronger is REQUIRED.  See Section
+12{FIXME} for the details regarding the choice of the hash function.
+
+For convenience, the synopsis of the encoding method is given below
+with significant simplifications attributable to the restricted choice
+of hash functions in this document.  However, [](#SP800-56A) is the
+normative source of the definition.
+
+    //   Implements KDF( X, oBits, Param );
+    //   Input: point X = (x,y)
+    //   oBits - the desired size of output
+    //   hBits - the size of output of hash function Hash
+    //   Param - octets representing the parameters
+    //   Assumes that oBits <= hBits
+    // Convert the point X to the octet string, see section 6{FIXME}:
+    //   ZB' = 04 || x || y
+    // and extract the x portion from ZB'
+    ZB = x;
+    MB = Hash ( 00 || 00 || 00 || 01 || ZB || Param );
+    return oBits leftmost bits of MB.
+
+Note that ZB in the KDF description above is the compact
+representation of X, defined in Section 4.2 of [](#RFC6090).
+
+## EC DH Algorithm (ECDH)
+
+The method is a combination of an ECC Diffie-Hellman method to
+establish a shared secret, a key derivation method to process the
+shared secret into a derived key, and a key wrapping method that uses
+the derived key to protect a session key used to encrypt a message.
+
+The One-Pass Diffie-Hellman method C(1, 1, ECC CDH) [](#SP800-56A)
+MUST be implemented with the following restrictions: the ECC CDH
+primitive employed by this method is modified to always assume the
+cofactor as 1, the KDF specified in Section 7 is used, and the KDF
+parameters specified below are used.
+
+The KDF parameters are encoded as a concatenation of the following 5
+variable-length and fixed-length fields, compatible with the
+definition of the OtherInfo bitstring [](#SP800-56A):
+
+  - a variable-length field containing a curve OID, formatted as
+    follows:
+
+      + a one-octet size of the following field
+
+      + the octets representing a curve OID, defined in Section 11
+
+  - a one-octet public key algorithm ID defined in Section 5
+
+  - a variable-length field containing KDF parameters, identical to
+    the corresponding field in the ECDH public key, formatted as
+    follows:
+
+      + a one-octet size of the following fields; values 0 and 0xff
+        are reserved for future extensions
+
+      + a one-octet value 01, reserved for future extensions
+
+      + a one-octet hash function ID used with the KDF
+
+      + a one-octet algorithm ID for the symmetric algorithm used to
+        wrap the symmetric key for message encryption; see Section 8
+        for details
+
+  - 20 octets representing the UTF-8 encoding of the string
+    "Anonymous Sender    ", which is the octet sequence
+    41 6E 6F 6E 79 6D 6F 75 73 20 53 65 6E 64 65 72 20 20 20 20
+
+  - 20 octets representing a recipient encryption subkey or a master
+    key fingerprint, identifying the key material that is needed for
+    the decryption.
+
+The size of the KDF parameters sequence, defined above, is either 54
+for the NIST curve P-256 or 51 for the curves P-384 and P-521.
+
+The key wrapping method is described in [](#RFC3394).  KDF produces a
+symmetric key that is used as a key-encryption key (KEK) as specified
+in [](#RFC3394).  Refer to Section 13{FIXME} for the details regarding the
+choice of the KEK algorithm, which SHOULD be one of three AES
+algorithms.  Key wrapping and unwrapping is performed with the default
+initial value of [](#RFC3394).
+
+The input to the key wrapping method is the value "m" derived from the
+session key, as described in Section 5.1{FIXME}, "Public-Key
+Encrypted Session Key Packets (Tag 1)", except that the PKCS #1.5
+padding step is omitted.  The result is padded using the method
+described in [](#PKCS5) to the 8-byte granularity.  For example, the
+following AES-256 session key, in which 32 octets are denoted from k0
+to k31, is composed to form the following 40 octet sequence:
+
+    09 k0 k1 ... k31 c0 c1 05 05 05 05 05
+
+The octets c0 and c1 above denote the checksum.  This encoding allows
+the sender to obfuscate the size of the symmetric encryption key used
+to encrypt the data.  For example, assuming that an AES algorithm is
+used for the session key, the sender MAY use 21, 13, and 5 bytes of
+padding for AES-128, AES-192, and AES-256, respectively, to provide
+the same number of octets, 40 total, as an input to the key wrapping
+method.
+
+The output of the method consists of two fields.  The first field is
+the MPI containing the ephemeral key used to establish the shared
+secret.  The second field is composed of the following two fields:
+
+  - a one-octet encoding the size in octets of the result of the key
+    wrapping method; the value 255 is reserved for future extensions;
+
+  - up to 254 octets representing the result of the key wrapping
+    method, applied to the 8-byte padded session key, as described
+    above.
+
+Note that for session key sizes 128, 192, and 256 bits, the size of
+the result of the key wrapping method is, respectively, 32, 40, and 48
+octets, unless the size obfuscation is used.
+
+For convenience, the synopsis of the encoding method is given below;
+however, this section, [](#SP800-56A), and [](#RFC3394) are the
+normative sources of the definition.
+
+    Obtain the authenticated recipient public key R
+    Generate an ephemeral key pair {v, V=vG}
+    Compute the shared point S = vR;
+    m = symm_alg_ID || session key || checksum || pkcs5_padding;
+    curve_OID_len = (byte)len(curve_OID);
+    Param = curve_OID_len || curve_OID || public_key_alg_ID || 03
+    || 01 || KDF_hash_ID || KEK_alg_ID for AESKeyWrap || "Anonymous
+    Sender    " || recipient_fingerprint;
+    Z_len = the key size for the KEK_alg_ID used with AESKeyWrap
+    Compute Z = KDF( S, Z_len, Param );
+    Compute C = AESKeyWrap( Z, m ) as per [RFC3394]
+    VB = convert point V to the octet string
+    Output (MPI(VB) || len(C) || C).
+
+The decryption is the inverse of the method given.  Note that the
+recipient obtains the shared secret by calculating
+
+    S = rV = rvG, where (r,R) is the recipient's key pair.
+
+Consistent with Section 5.13{FIXME}, "Sym. Encrypted Integrity
+Protected Data Packet (Tag 18)", a Modification Detection Code (MDC)
+MUST be used anytime the symmetric key is protected by ECDH.
+
+
 # {13} Notes on Algorithms
 
 ## {13.1}  PKCS\#1 Encoding in OpenPGP
@@ -3449,9 +3735,8 @@ ## {13.8} Reserved Algorithm Numbers
 algorithm.  These are marked in Section 9.1, "Public-Key Algorithms",
 as "reserved for".
 
-The reserved public-key algorithms, Elliptic Curve (18), ECDSA (19),
-and X9.42 (21), do not have the necessary parameters, parameter order,
-or semantics defined.
+The reserved public-key algorithm X9.42 (21) does not have the
+necessary parameters, parameter order, or semantics defined.
 
 Previous versions of OpenPGP permitted Elgamal [](#ELGAMAL) signatures
 with a public-key identifier of 20.  These are no longer permitted.  An
@@ -3636,7 +3921,7 @@ # {14} Security Considerations
     taken that the weakest element of an OpenPGP message is still
     sufficiently strong for the purpose at hand.  While consensus about
     the strength of a given algorithm may evolve, NIST Special
-    Publication 800-57 [SP800-57] recommends the following list of
+    Publication 800-57 [](#SP800-57) recommends the following list of
     equivalent strengths:
 
              Asymmetric  |  Hash  |  Symmetric
@@ -3750,6 +4035,156 @@ # {14} Security Considerations
     data is decrypted.  There are many cases in cryptographic engineering
     where the implementer must use care and wisdom, and this is one.
 
+  - Refer to [](#FIPS186-3), B.4.1, for the method to generate a
+    uniformly distributed ECC private key.
+
+  - The curves proposed in this document correspond to the symmetric
+    key sizes 128 bits, 192 bits, and 256 bits, as described in the
+    table below.  This allows a compliant application to offer
+    balanced public key security, which is compatible with the
+    symmetric key strength for each AES algorithm defined here.
+
+    The following table defines the hash and the symmetric encryption
+    algorithm that SHOULD be used with a given curve for ECDSA or ECDH.
+    A stronger hash algorithm or a symmetric key algorithm MAY be used
+    for a given ECC curve.  However, note that the increase in the
+    strength of the hash algorithm or the symmetric key algorithm may
+    not increase the overall security offered by the given ECC key.
+
+            Curve name | ECC      | RSA         | Hash size | Symmetric
+                       | strength | strength,   |           | key size
+                       |          | informative |           |
+            -----------+----------+-------------+-----------+-----------
+            NIST P-256      256         3072         256         128
+            NIST P-384      384         7680         384         192
+            NIST P-521      521        15360         512         256
+
+    Requirement levels indicated elsewhere in this document lead to the
+    following combinations of algorithms in the OpenPGP profile: MUST
+    implement NIST curve P-256 / SHA2-256 / AES-128, SHOULD implement
+    NIST curve P-521 / SHA2-512 / AES-256, MAY implement NIST curve
+    P-384 / SHA2-384 / AES-256, among other allowed combinations.
+
+    Consistent with the table above, the following table defines the KDF
+    hash algorithm and the AES KEK encryption algorithm that SHOULD be
+    used with a given curve for ECDH.  A stronger KDF hash algorithm or
+    AES KEK algorithm MAY be used for a given ECC curve.
+
+            Curve name | Recommended KDF | Recommended KEK
+                       | hash algorithm  | encryption algorithm
+            -----------+-----------------+-----------------------
+            NIST P-256      SHA2-256            AES-128
+            NIST P-384      SHA2-384            AES-192
+            NIST P-521      SHA2-512            AES-256
+
+    This document explicitly discourages the use of algorithms other
+    than AES as a KEK algorithm because backward compatibility of the
+    ECDH format is not a concern.  The KEK algorithm is only used within
+    the scope of a Public-Key Encrypted Session Key Packet, which
+    represents an ECDH key recipient of a message.  Compare this with
+    the algorithm used for the session key of the message, which MAY be
+    different from a KEK algorithm.
+
+    Compliant applications SHOULD implement, advertise through key
+    preferences, and use the strongest algorithms specified in this
+    document.
+
+    Note that the symmetric algorithm preference list may make it
+    impossible to use the balanced strength of symmetric key algorithms
+    for a corresponding public key.  For example, the presence of the
+    symmetric key algorithm IDs and their order in the key preference
+    list affects the algorithm choices available to the encoding side,
+    which in turn may make the adherence to the table above infeasible.
+    Therefore, compliance with this specification is a concern
+    throughout the life of the key, starting immediately after the key
+    generation when the key preferences are first added to a key.  It is
+    generally advisable to position a symmetric algorithm ID of strength
+    matching the public key at the head of the key preference list.
+
+    Encryption to multiple recipients often results in an unordered
+    intersection subset.  For example, if the first recipient's set is
+    {A, B} and the second's is {B, A}, the intersection is an unordered
+    set of two algorithms, A and B.  In this case, a compliant
+    application SHOULD choose the stronger encryption algorithm.
+
+    Resource constraints, such as limited computational power, is a
+    likely reason why an application might prefer to use the weakest
+    algorithm.  On the other side of the spectrum are applications that
+    can implement every algorithm defined in this document.  Most
+    applications are expected to fall into either of two categories.  A
+    compliant application in the second, or strongest, category SHOULD
+    prefer AES-256 to AES-192.
+
+    SHA-1 MUST NOT be used with the ECDSA or the KDF in the ECDH method.
+
+    MDC MUST be used when a symmetric encryption key is protected by
+    ECDH.  None of the ECC methods described in this document are
+    allowed with deprecated V3 keys.  A compliant application MUST only
+    use iterated and salted S2K to protect private keys, as defined in
+    Section 3.7.1.3{FIXME}, "Iterated and Salted S2K".
+
+    Side channel attacks are a concern when a compliant application's
+    use of the OpenPGP format can be modeled by a decryption or signing
+    oracle model, for example, when an application is a network service
+    performing decryption to unauthenticated remote users.  ECC scalar
+    multiplication operations used in ECDSA and ECDH are vulnerable to
+    side channel attacks.  Countermeasures can often be taken at the
+    higher protocol level, such as limiting the number of allowed
+    failures or time-blinding of the operations associated with each
+    network interface.  Mitigations at the scalar multiplication level
+    seek to eliminate any measurable distinction between the ECC point
+    addition and doubling operations.
+
+
+# Compatibility Profiles
+
+## OpenPGP ECC Profile
+
+A compliant application MUST implement NIST curve P-256, MAY implement
+NIST curve P-384, and SHOULD implement NIST curve P-521, as defined in
+Section 11.  A compliant application MUST implement SHA2-256 and
+SHOULD implement SHA2-384 and SHA2-512.  A compliant application MUST
+implement AES-128 and SHOULD implement AES-256.
+
+A compliant application SHOULD follow Section 13{FIXME} regarding the
+choice of the following algorithms for each curve:
+
+  - the KDF hash algorithm,
+  - the KEK algorithm,
+  - the message digest algorithm and the hash algorithm used in the
+    key certifications,
+  - the symmetric algorithm used for message encryption.
+
+It is recommended that the chosen symmetric algorithm for message
+encryption be no less secure than the KEK algorithm.
+
+## Suite-B Profile
+
+A subset of algorithms allowed by this document can be used to achieve
+[](#SuiteB) compatibility.  The references to [](#SuiteB) in this
+document are informative.  This document is primarily concerned with
+format specification, leaving additional security restrictions
+unspecified, such as matching the assigned security level of
+information to authorized recipients or interoperability concerns
+arising from fewer allowed algorithms in [](#SuiteB) than allowed by
+this document.
+
+## Security Strength at 192 Bits
+
+To achieve the security strength of 192 bits, [](#SuiteB) requires
+NIST curve P-384, AES-256, and SHA2-384.  The symmetric algorithm
+restriction means that the algorithm of KEK used for key wrapping in
+Section 8 and an OpenPGP session key used for message encryption must
+be AES-256.  The hash algorithm restriction means that the hash
+algorithms of KDF and the OpenPGP message digest calculation must be
+SHA-384.
+
+## Security Strength at 128 Bits
+
+The set of algorithms in Section 12.2.1{FIXME} is extended to allow NIST
+curve P-256, AES-128, and SHA2-256.
+
+
 # {15} Implementation Nits
 
 This section is a collection of comments to help an implementer,

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: "Derek Atkins" <[email-masked]>
Date: Fri, 29 May 2015 15:56:32 -0400

I notice you did not add the text for Ed25519?
Is that for a future update?

-derek

On Fri, May 29, 2015 3:40 pm, Werner Koch wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 29 May 2015 16:26:09 -0400

> Is that for a future update?

Please don't do Ed25519 right now.

Let the CFRG folk finish first.

Otherwise we will end up with two different versions.

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 29 May 2015 22:56:26 +0200

> Otherwise we will end up with two different versions.

Different versions of what?  Ed25519 is well defined and implemented
already, as far as I understand.  If CFRG recommends something other
than Ed25519 (which is possible), that doesn't change that there is
already momentum and deployed code for Ed25519 in OpenPGP.

/Simon

---

From: "Mark D. Baushke" <[email-masked]>
Date: Fri, 29 May 2015 14:04:17 -0700

> Otherwise we will end up with two different versions.

+1 

It may be desirable to have a family EdDSA of Edwards curves rather than
just the Ed25519 entry. Let's wait to see the IEF CFRG finding.

	-- Mark

---

From: Werner Koch <[email-masked]>
Date: Sat, 30 May 2015 12:04:55 +0200

> I notice you did not add the text for Ed25519?

It is not an RFC thus it can't be added without discussion.

Shalom-Salam,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Sat, 30 May 2015 12:09:42 +0200

> just the Ed25519 entry. Let's wait to see the IEF CFRG finding.

My I-D already does this:

draft-koch-eddsa-for-openpgp-02.txt:

   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.

It might be useful to replace the reference id

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

to [EDDSA] for clarity.  And we should push for Simon's EDDSA draft to
become an RFC.

Salam-Shalom,

   Werner