JEP 339: Edwards-Curve Digital Signature Algorithm (EdDSA)

AuthorAdam Petcher
OwnerAnthony Scarpino
StatusClosed / Delivered
Componentsecurity-libs / javax.crypto
Discussionsecurity dash dev at openjdk dot java dot net
Reviewed bySean Mullan
Endorsed byAlan Bateman
Created2018/03/07 15:14
Updated2020/10/13 21:55


Implement cryptographic signatures using the Edwards-Curve Digital Signature Algorithm (EdDSA) as described by RFC 8032.


EdDSA is a modern elliptic curve signature scheme that has several advantages over the existing signature schemes in the JDK. The primary goal of this JEP is an implementation of this scheme as standardized in RFC 8032. This new signature scheme does not replace ECDSA.

Additional implementation goals:


Success Metrics


EdDSA is in demand due to its improved security and performance compared to other signature schemes, and is already supported in many other crypto libraries such as OpenSSL and BoringSSL. This signature scheme is an optional component of TLS 1.3, but is one of only three signature schemes that are allowed in TLS 1.3. Some users may have EdDSA certificates, and may have a strong preference to use EdDSA. These users will appreciate the ability to use EdDSA without having to use a third-party library. An additional benefit of developing an implementation of EdDSA is that it allows us to more easily develop and test the support of this algorithm in TLS 1.3.


New Signature, KeyFactory, and KeyPairGenerator services will be added to the SunEC provider to support EdDSA. New classes and interfaces will be added to the API to represent EdDSA keys, and new standard algorithm names will be added to describe EdDSA signature schemes. The API and implementation will support all EdDSA variants (pure, prehashed, and context).

The point arithmetic will use the double and add operations defined in RFC 8032 along with a branch-free conditional assignment operation to prevent side-channel attacks. The field arithmetic will use the modular arithmetic library that was developed for XDH (JEP 324). The combined implementation will not leak secrets into timing and cache side channels, under some reasonable assumptions on the behavior of the JVM and hardware.

The API will reuse the NamedParameterSpec class developed for XDH in order to describe curve domain parameters and EdDSA variants. New classes and interfaces will be developed for Edwards curve points, EdDSA keys, and signature parameters which include context information.

Example API usage:

// example: generate a key pair and sign
KeyPairGenerator kpg = KeyPairGenerator.getInstance("Ed25519");
KeyPair kp = kpg.generateKeyPair();
// algorithm is pure Ed25519
Signature sig = Signature.getInstance("Ed25519");
byte[] s = sig.sign();

// example: use KeyFactory to contruct a public key
KeyFactory kf = KeyFactory.getInstance("EdDSA");
boolean xOdd = ...
BigInteger y = ...
NamedParameterSpec paramSpec = new NamedParameterSpec("Ed25519");
EdECPublicKeySpec pubSpec = new EdECPublicKeySpec(paramSpec, new EdPoint(xOdd, y));
PublicKey pubKey = kf.generatePublic(pubSpec);



Testing will include the test vectors from RFC 8032, augmented with tests for corner cases such as small subgroups and non-canonical values.

Risks and Assumptions

The EdDSA implementation will use the field arithmetic library developed for XDH, so there is the same risk of overflow and other bugs that produce incorrect results. This risk is mitigated by continuing to analyze and test the field arithmetic library.