Re: [TLS] Updated EdDSA/Ed25519 PKIX document

"Blumenthal, Uri - 0553 - MITLL" <> Thu, 24 September 2015 14:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id BFBCD1A6F39 for <>; Thu, 24 Sep 2015 07:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.609
X-Spam-Status: No, score=-3.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_47=0.6, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ogGJ5-z4nP9J for <>; Thu, 24 Sep 2015 07:49:35 -0700 (PDT)
Received: from (MX1.LL.MIT.EDU []) by (Postfix) with ESMTP id C0E0B1A6FF1 for <>; Thu, 24 Sep 2015 07:49:34 -0700 (PDT)
Received: from ( by (unknown) with ESMTP id t8OEnCH9029342; Thu, 24 Sep 2015 10:49:24 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <>
To: Nikos Mavrogiannopoulos <>, Ilari Liusvaara <>, Simon Josefsson <>
Thread-Topic: [TLS] Updated EdDSA/Ed25519 PKIX document
Thread-Index: AdD214EF47//3lyQuEOdqxqLWMQxEA==
Date: Thu, 24 Sep 2015 14:44:24 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="SHA1"; boundary="===============1248462120=="
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-24_06:2015-09-23,2015-09-24,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509240215
Archived-At: <>
Cc: "" <>
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 14:49:36 -0000

For this reason (among others) I am against PureEdDSA. ‎HashEdDSA dooes the job well enough. 

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Nikos Mavrogiannopoulos
Sent: Thursday, September 24, 2015 10:04
To: Ilari Liusvaara; Simon Josefsson
Subject: Re: [TLS] Updated EdDSA/Ed25519 PKIX document

On Thu, 2015-09-24 at 15:27 +0300, Ilari Liusvaara wrote:

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

The problem with the PureEdDSA is that if you use a smart card or an
HSM (both common for TLS), you have to transfer lots of data to them,
something that may render it not really useful. Also the PureEdDSA in
most implementations it requires a new API for signing.


TLS mailing list