Re: [TLS] Updated EdDSA/Ed25519 PKIX document

Ilari Liusvaara <> Thu, 24 September 2015 12:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 26EDA1A9145; Thu, 24 Sep 2015 05:27:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.301
X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U3N_1TZRQyiJ; Thu, 24 Sep 2015 05:27:50 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CBF571A913D; Thu, 24 Sep 2015 05:27:49 -0700 (PDT)
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id AA0D4699FB; Thu, 24 Sep 2015 15:27:47 +0300 (EEST)
Date: Thu, 24 Sep 2015 15:27:47 +0300
From: Ilari Liusvaara <>
To: Simon Josefsson <>
Message-ID: <20150924122747.GA10461@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: Ilari Liusvaara <>
Archived-At: <>
Subject: Re: [TLS] Updated EdDSA/Ed25519 PKIX document
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 24 Sep 2015 12:27:52 -0000

On Wed, Sep 23, 2015 at 10:33:29AM +0200, Simon Josefsson wrote:
> Hi all,
> I have pushed out a new version of the document describing EdDSA public
> keys, signatures and certificates for PKIX.  The change in -03 include
> the addition of the prehash mode, test vectors generated by GnuTLS, and
> a section recommending certain human readable names.
> I've started a thread to discuss whether it is wortwhile to be able to
> use the same Ed25519 key for both PureEdDSA mode and HashEdDSA signing,
> and I'd appreciate feedback on whether people are interested in this and
> generally if it is a good idea or not.  The complexity involved make me
> shy away a bit from it, but it is fun to consider.  The thread is here:

Some comments:

1) Taking private key example and decoding the ASN.1 yields:

  0  37: SEQUENCE {
  2   1:   ENUMERATED 1
  5  32:   OCTET STRING
       :     D4 EE 72 DB F9 13 58 4A D5 B6 D8 F1 F7 69 F8 AD
       :     3A FE 7C 28 CB F1 D4 FB E0 97 A8 8F 44 75 58 42
       :   }

What is that ENUMERATED 1 for? The text description has algorithm of 
SHA512-Ed25519, which would AFAICT be ENUMERATED 2 if private keys use
the same kind enumeration as public keys.

2) AFAICT, EdDSA-20150704 calls the signature without prehash, with
25519 curve and SHA-512 hash "Ed25519-SHA-512" (and the corresponding
version with SHA-512 prehash "SHA-512-Ed25519-SHA-512").

The first of those is AFAIK the same as the old "Ed25519" signature

One problem with those names is that those things might get rather
nasty to read when '-' both appears inside hash names and component

3) Using the same key for both PureEdDSA and HashEdDSA sounds like a
bad idea. However, it would be technically possible to alter the
internal subkey derivation so that different prehashes give logically
separate keys.

Such change would only affect signing, not verification (since verifier
sees the change as different public key).

4) For TLS PoP signatures, does it make sense to use HashEdDSA at all?
Another way would to always use PureEdDSA and perform hash separtion
from TLS side (e.g. sign(privkey, hash_func_id|H(tbs_data))).

The certificate signatures are different matter tho, since CAs use
HSMs for signing (those HSMs tend to be rather beefy, but still).

Then there are CRLs. I would imagine those are so large that one rather
uses prehashing.