# Can the EdDSA signature scheme be customized with OpenSSL?

EdDSA has currently 2 signature scheme Ed25519 and Ed448 where

• Ed25519 is the EdDSA signature scheme using SHA-512 (SHA-2) and Curve25519

• Ed448 is the EdDSA signature scheme using SHAKE256 (SHA-3) and Curve448

1. Is it possible to use EdDSA with a custom algorithm (signature scheme) for instance a different curve and a different hashing algorithm like SHA-1?
2. Is this not possible because of an RFC standard?
3. Are there any cryptographic reasons why OpenSSL does not provide EdDSA that use other curves?
4. Does this have to do with OpenSSL not having the feature implemented?
• What do you mean with “rigid” by design? – xorhash Jul 12 at 14:30
• what i mean by rigid is that it is meant to be implemented with a limited available algorithm may be only Ed448 and Ed25519 – flowb Jul 12 at 15:16
• Why do you want to use a custom algorithm? Do you want to implement your scheme? Go on the source code and add it. – kelalaka Jul 12 at 15:49
• @kelalaka I just want to learn about it, if it is designed to permit such thing with OpenSSL or not... without changing the source code – flowb Jul 12 at 16:56
• @mentallurg i updated the question as suggested – flowb Jul 12 at 23:55

The first thing to clarify is the definition of “EdDSA”. EdDSA was introduced in Bernstein et al.'s High-speed high-security signatures in 2011. Various parameters it implicitly assumed were declared more generally in the 2015 paper Bernstein et al., EdDSA for more curves. This culminated in an RFC Edwards-Curve Digital Signature Algorithm (EdDSA), RFC 8032 from 2017.

All of them describe EdDSA abstractly and then instantiate it with a set of concrete parameters. Thus, Ed25519 and Ed448 are specific sets of parameters for EdDSA that form a concrete signature scheme that can be implemented.

1. Is it possible to use EdDSA with a custom algorithm (signature scheme) for instance a different curve and a different hashing algorithm like SHA-1?

Yes, this is possible, assuming you do not mean the specific instantiations in the first paper and RFC 8032.

In fact, the Monocypher cryptography library's crypto_sign() does exactly that, swapping out SHA-512 in favor of BLAKE2b.

1. Is this not possible because of an RFC standard?

As noted above, this is possible, but the result obviously wouldn't be able to be called “Ed25519” or “Ed448” because it'd be incompatible with those specific instantiations.

1. Does this mean that EdDSA is rigid by design?

It isn't, no. The 2015 paper even goes out of its way to add a bunch of.

EdDSA as specified in all of these documents is somewhat inflexible with regards to the underlying curve, however: It assumes that the cofactor $$h=2^c$$ has $$c\in\{2,3\}$$, which rules out prime-order Weierstrass curves for example. The required modifications to be able to not require $$c$$ with a prime-order curve are both trivial and obvious, but this specific set of permissible values for $$c$$ mandated by all specifications of EdDSA.

1. Does this have to do with OpenSSL not having the feature implemented?

No, nobody specifying EdDSA cared what OpenSSL does because that'd be putting the cart before the horse: OpenSSL can't implement EdDSA before it is specified.