Ed25519 support in the OpenSSL compatibility layer

[ordex]

Description

wolfCrypt has full Ed25519 (keygen, sign/verify, ASN.1 import/export) and the TLS 1.3 stack already authenticates with Ed25519 certificates, but the OpenSSL-compatibility surface was missing the dispatch for several common operations, so an application driving Ed25519 purely through the OpenSSL API (EVP_PKEY_keygen, i2d_PUBKEY, X509_sign of an in-memory self-signed cert, then loading it into an SSL_CTX) could not use it.

This PR adds the required glue code to have full OpenSSL API support for Ed25591 (by mirroring the existing RSA/ECC/X25519 code).

Note: requires --enable-ed25519 --enable-certgen

Testing

The commit comes with the relevant unit test code.
Moreover, this code is used by an experimental TLS-based VPN client that uses Ed25591 keys/certs.

[wolfSSL-Bot]

Can one of the admins verify this patch?

[dgarske]

Hi @ordex , this is a very nice contribution. I'd like to hear more about your project and use case. In order to accept this we need some more information and a signed contributor agreement. Please email support@wolfssl.com and reference this PR. Thank you so much, David Garske, wolfSSL

[github-actions]

MemBrowse Memory Report

linuxkm-standard

• Data: __patchable_function_entries -8 B (-0.0%, 46,000 B)
  No memory changes detected for:
• gcc-arm-cortex-m0plus
• gcc-arm-cortex-m3
• gcc-arm-cortex-m4
• gcc-arm-cortex-m4-baremetal
• gcc-arm-cortex-m4-crypto-only
• gcc-arm-cortex-m4-dtls13
• gcc-arm-cortex-m4-min-ecc
• gcc-arm-cortex-m4-openssl-compat
• gcc-arm-cortex-m4-pkcs7
• gcc-arm-cortex-m4-pq
• gcc-arm-cortex-m4-rsa-only
• gcc-arm-cortex-m4-sp-math
• gcc-arm-cortex-m4-tls12
• gcc-arm-cortex-m4-tls13
• gcc-arm-cortex-m7
• gcc-arm-cortex-m7-pq
• gcc-arm-cortex-m7-tls13
• linuxkm-pie
• stm32-sim-stm32h753

[ordex]

Hi @dgarske I reached out to support and I am sorting out the agreement.
Meanwhile I saw that I made a mistake in the unit-test (some workflow failed on it) and I force pushed a change.

Regarding my project: I am working on a slim openvpn-compatible client and it is expected to perform the TLS handshake using Ed25519 keys. While this works flawlessly with OpenSSL, I hit the mentioned limitation with wolfSSL.

The reason for using also wolfSSL, next to OpenSSL, is because I am planning to deploy the client on OpenWrt, which may ship with wolfSSL only.

[dgarske]

Okay to test. Thank you @ordex for those details and working with us on the contributor agreement. I see your ZD ticket 22003.

[Copilot]

Pull request overview

This PR extends wolfSSL’s OpenSSL-compatibility layer to fully support Ed25519 workflows (EVP keygen, PKCS#8/SPKI serialization, X509 self-signing, and SSL_CTX loading), aligning the OpenSSL API surface with existing wolfCrypt/TLS Ed25519 capabilities.

Changes:

• Add Ed25519 support to EVP_PKEY_keygen() and public-key DER serialization (i2d_PUBKEY / i2d_PublicKey).
• Improve Ed25519 PKCS#8 decode handling and ensure decoded private keys have a derived public component.
• Add an API-level unit test exercising an application-like Ed25519 EVP/X509/TLS flow.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 9 comments.

Show a summary per file

File	Description
wolfcrypt/src/evp.c	Adds Ed25519 handling to EVP_PKEY key generation and caches PKCS#8 DER.
wolfcrypt/src/evp_pk.c	Improves Ed25519 PKCS#8 decode behavior and adds SPKI encoding for Ed25519 public keys.
src/x509.c	Adds Ed25519 pubkey extraction/import, Ed25519 signing handling with NULL digest, and X509 pubkey setting.
src/pk.c	Extends PKCS#8 encoding logic to return cached Ed25519 PKCS#8 bytes.
tests/api.c	Adds an end-to-end Ed25519 OpenSSL-compat EVP/X509/SSL_CTX unit test.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[dgarske]

Skoll Code Review

Scan type: reviewOverall recommendation: REQUEST_CHANGES
Findings: 13 total — 13 posted, 0 skipped
12 finding(s) posted as inline comments (see file-level comments below)

Posted findings

• [High] Ed25519 pubkey import in CertFromX509/wolfssl_x509_make_der not gated on HAVE_ED25519_KEY_IMPORT — src/x509.c:12522-12550
• [High] Ed25519 import paths missing HAVE_ED25519_KEY_IMPORT guard (build break) — src/x509.c:6582, src/x509.c:12522
• [High] Ed25519 public-key decode in wolfSSL_X509_get_pubkey not gated on HAVE_ED25519_KEY_IMPORT — src/x509.c:6582-6610
• [Medium] pkcs8_encode Ed25519 special case lacks NULL guard on pkey-pkey.ptr — src/pk.c:7377-7392
• [Medium] Non-ASCII em-dash in comment violates wolfSSL ASCII-only convention — src/pk.c:7380
• [Medium] Ed25519 keygen path uses KEY_EXPORT guard but calls MAKE_KEY-only wc_ed25519_make_key — wolfcrypt/src/evp.c:3939-3958
• [Medium] wc_ed25519_make_public derive call requires HAVE_ED25519_MAKE_KEY guard — wolfcrypt/src/evp_pk.c:286-295
• [Low] pkcs8_encode Ed25519 branch assumes cached DER is a private PKCS#8 without validating — src/pk.c:7377-7392
• [Low] Non-ASCII em-dash in comment violates ASCII-only convention — src/pk.c:7380
• [Low] Use CTC_ED25519 instead of ED25519k for signature-type return value — src/x509.c:12264-12269
• [Low] Doxygen comment detached from wolfSSL_i2d_PublicKey by inserted helper — wolfcrypt/src/evp_pk.c:2402-2457
• [Low] i2d_PublicKey for Ed25519 emits SubjectPublicKeyInfo rather than the raw key — wolfcrypt/src/evp_pk.c:2459-2488
• [Low] Redundant pubKeySet assignment and ignored make_public failure — wolfcrypt/src/evp_pk.c:290-295

Review generated by Skoll

[dgarske]

🔴 [High] Ed25519 pubkey import in CertFromX509/wolfssl_x509_make_der not gated on HAVE_ED25519_KEY_IMPORT

The new Ed25519 public-key object-creation block is guarded only by #if defined(HAVE_ED25519) but calls wc_ed25519_import_public() (KEY_IMPORT-only, ed25519.c:1235-1469). With HAVE_ED25519 but NO_ED25519_KEY_IMPORT, this block is compiled and references an unbuilt symbol, breaking the link. The matching cleanup block at src/x509.c:12803-12808 uses only wc_ed25519_free/XFREE (always available) so it does not have the same problem, but the import site does.

Fix: Add && defined(HAVE_ED25519_KEY_IMPORT) to the #if guard around the ED25519k public-key decode block.

[dgarske]

🔴 [High] Ed25519 public-key decode in wolfSSL_X509_get_pubkey not gated on HAVE_ED25519_KEY_IMPORT

The new Ed25519 decode block is guarded only by #if defined(HAVE_ED25519), but it calls wc_ed25519_import_public(), which is compiled only under #ifdef HAVE_ED25519_KEY_IMPORT (wolfcrypt/src/ed25519.c:1235-1469). settings.h defines HAVE_ED25519_KEY_IMPORT by default with HAVE_ED25519, but a user can disable it independently via NO_ED25519_KEY_IMPORT while keeping HAVE_ED25519. In that supported configuration this code still compiles and produces an undefined reference / link error. Note the sibling wolfSSL_X509_set_pubkey (added in this same PR) correctly guards with HAVE_ED25519 && HAVE_ED25519_KEY_EXPORT, so the precise-guard precedent already exists in the diff.

Fix: Change the guard to #if defined(HAVE_ED25519) && defined(HAVE_ED25519_KEY_IMPORT) so the block (and the key->type = WC_EVP_PKEY_ED25519 assignment that feeds it) is only built when the import primitive is available.

[dgarske]

🟠 [Medium] pkcs8_encode Ed25519 special case lacks NULL guard on pkey-pkey.ptr

The new Ed25519 branch copies the cached DER with XMEMCPY(key, pkey->pkey.ptr, pkey->pkey_sz) but only checks keySz == NULL. Unlike the DH special case it mirrors, it does not validate that pkey->pkey.ptr (or pkey->ed25519) is non-NULL / pkey_sz > 0. The DH branch above is reached only after confirming pkey->dh->priv_key || pub_key are set, which implies the buffer is populated; the Ed25519 branch has no such precondition. An Ed25519 WOLFSSL_EVP_PKEY whose pkey.ptr was never cached (e.g. a key populated only via the in-memory ed25519 object) would dereference NULL here.

Fix: Add a pkey->pkey.ptr == NULL || pkey->pkey_sz <= 0 guard before the copy, returning BAD_FUNC_ARG, to match the defensive style of the surrounding branches.

[dgarske]

🟠 [Medium] Non-ASCII em-dash in comment violates wolfSSL ASCII-only convention

The new comment contains a UTF-8 em-dash (U+2014) instead of an ASCII hyphen: "so return it as-is — same as the". wolfSSL source is expected to be 7-bit ASCII only; this is the sole non-ASCII byte introduced across all five changed files and will trip ASCII/whitespace lint checks. Use - (or --) instead.

Fix: Replace the em-dash with an ASCII hyphen to comply with the repository's ASCII-only source policy.

[dgarske]

🟠 [Medium] Ed25519 keygen path uses KEY_EXPORT guard but calls MAKE_KEY-only wc_ed25519_make_key

The Ed25519 keygen case (and the corresponding type allowlist at evp.c:3824-3826) is guarded by HAVE_ED25519 && HAVE_ED25519_KEY_EXPORT, but the body calls wc_ed25519_make_key(), which exists only under HAVE_ED25519_MAKE_KEY (ed25519.c:266-409). A build with key export enabled but NO_ED25519_MAKE_KEY (hence NO_ED25519_SIGN) would compile the case yet fail to link. Less common than the KEY_IMPORT cases, but the guard does not match the primitives used.

Fix: Add && defined(HAVE_ED25519_MAKE_KEY) to the Ed25519 keygen guard (both the case label and the allowlist check).

[dgarske]

🔵 [Low] Non-ASCII em-dash in comment violates ASCII-only convention

The comment introduced by this PR contains a UTF-8 em-dash (U+2014) rather than ASCII. wolfSSL source must be 7-bit ASCII (no em/en dashes, smart quotes, etc.). This is the only non-ASCII byte introduced across the changed files (verified via a non-ASCII scan of all five files; the rest are clean).

Fix: Replace the em-dash with -- (or -) so the file remains pure ASCII.

[dgarske]

🔵 [Low] Use CTC_ED25519 instead of ED25519k for signature-type return value

wolfSSL_sigTypeFromPKEY returns a signature-type constant (e.g. CTC_SHA256wECDSA), but the new Ed25519 path returns the key-OID constant ED25519k. These happen to be numerically identical (both are 256 / OID 1.3.101.112, per oid_sum.h), so behavior is correct, but returning the CTC_* signature-type constant from a function whose contract is "sig type" reads more clearly and matches the other branches.

Fix: Return CTC_ED25519 (identical value, clearer intent) for consistency with the RSA/ECC CTC_* returns in this function.

[dgarske]

🔵 [Low] Doxygen comment detached from wolfSSL_i2d_PublicKey by inserted helper

The new wolfssl_i_i2d_ed25519_pubkey() helper (and its own block comment) was inserted between the existing doc-block that documents wolfSSL_i2d_PublicKey ("Encode the WOLFSSL_EVP_PKEY object as public key DER...") and the function it describes. The doc-block now sits immediately above the static helper, so it reads as documentation for the helper rather than for wolfSSL_i2d_PublicKey. Purely a readability issue.

Fix: Relocate the inserted helper above the existing function doc-block to keep the documentation attached to wolfSSL_i2d_PublicKey.

[dgarske]

🔵 [Low] i2d_PublicKey for Ed25519 emits SubjectPublicKeyInfo rather than the raw key

The new Ed25519 case routes wolfSSL_i2d_PublicKey to wolfssl_i_i2d_ed25519_pubkey() with withAlg=1, i.e. it emits a full SubjectPublicKeyInfo. In OpenSSL i2d_PublicKey emits the bare/traditional key while i2d_PUBKEY emits the SPKI. wolfSSL aliases i2d_PUBKEY directly to i2d_PublicKey (evp_pk.c:2499-2502), so the SPKI form is what the PEM_write_bio_PUBKEY path needs and the new test's i2d_PUBKEY round-trip passes. The note is only that a caller invoking wolfSSL_i2d_PublicKey for Ed25519 expecting the 32 raw bytes (OpenSSL semantics) will instead get the SPKI. This matches the alias's behavior, so it is likely intentional; flagging for confirmation.

Fix: Confirm the SPKI output is the intended behavior for both the i2d_PUBKEY and i2d_PublicKey entry points; if a raw form is ever needed for i2d_PublicKey, gate it on the caller. No change required if the alias semantics are accepted.

[dgarske]

🔵 [Low] Redundant pubKeySet assignment and ignored make_public failure

wc_ed25519_make_public() already sets key->pubKeySet = 1 internally on success (ed25519.c:353), so the explicit edKey->pubKeySet = 1; is redundant. Additionally, a non-zero return from wc_ed25519_make_public() is silently swallowed: if derivation fails, the code proceeds to build the EVP_PKEY with no public part and no diagnostic. This is acceptable degradation but could at least emit a WOLFSSL_MSG.

Fix: Drop the redundant flag assignment (rely on make_public) and optionally log when derivation fails.

[julek-wolfssl]

This is great work. I would like to see the following tests included too:

• Raw-key paths, e.g. EVP_PKEY_new_raw_private_key() / EVP_PKEY_new_raw_public_key(), since those may populate pkey->pkey.ptr differently than keygen/decode.
• Validation that a PKCS#8-decoded Ed25519 private key can re-export the same public key / SPKI, not just that d2i_AutoPrivateKey() returns non-NULL.
• Negative coverage for public-only Ed25519 keys: PKCS#8 private export should fail cleanly, not emit raw public bytes or cached non-PKCS#8 data.
• Certificate verification after X509_sign(..., NULL), to prove the generated Ed25519 signature/OID/public-key encoding is actually usable.

[julek-wolfssl]

Prefer to use wolfSSL_ED25519_new.

[julek-wolfssl]

Also use wolfSSL_ED25519_new

[julek-wolfssl]

Let's separate this check out into a new block after this one. Something like this. I suspect other algos in the future will have similar edge cases.

if (md == null) {
  if (pkey->type != WC_EVP_PKEY_ED25519)
    error;
}

[julek-wolfssl]

wolfSSL_ED25519_new

[julek-wolfssl]

Suggested change

	if (pkey->pkey.ptr != NULL) {
	XFREE(pkey->pkey.ptr, pkey->heap,
	DYNAMIC_TYPE_OPENSSL);
	}
	XFREE(pkey->pkey.ptr, pkey->heap,
	DYNAMIC_TYPE_OPENSSL);

[dgarske]

Hi @ordex , your contributor agreement has been approved and is now on file. We posted some review feedback, so take a look at those. Looking forward to your next push.
Thanks, David Garske, wolfSSL