Feat: Added support for JWK decoding Ed25519 keys by richy1623 · Pull Request #506 · Keats/jsonwebtoken

richy1623 · 2026-04-28T08:53:56Z

Summary: Added decoding JWK support for Ed25519 keys

Changes:

Implemented the unimplemented Jwk::from_encoding_key when Algorithm::EdDSA
Added to the JWK utils to support fetching Ed25519
Updated both backends to support extracting the x parameter (https://datatracker.ietf.org/doc/html/rfc8037#section-2)
Added a new EllipticCurve type Ed448 for Ed448 curves
Updated the decoder to allow decoding PEMs of type Ed448
Added tests for all changes

Solves: #244

…decode_ed25519

richy1623 · 2026-06-14T11:48:17Z

Thanks for the review @arckoor! I have implemented the requested changes if I could please get a re-review.

arckoor

Sorry this took so long to get back to.
Classifying Ed448 curves properly and later on rejecting them with UnsupportedAlgorithm is a nice idea, however doing it like this is misleading for PEM users:

let privkey_pem = include_bytes!("private_ed448_key.pem");
let encoding_key = EncodingKey::from_ed_pem(privkey_pem).unwrap(); // this succeeds

let claims = Claims {... };
let token = encode(&Header::new(Algorithm::EdDSA), &claims, &encoding_key).unwrap(); // obviously fails because it's not EdDSA, but there is also no Ed448 algorithm here :/

If I can construct a (PEM) key, I'd expect to be able to sign with it.
So I'd prefer if that bit were removed. Should also mean that you don't need classify_ed_curve at all anymore, and can just match based on key length

arckoor · 2026-06-18T13:14:40Z

    pkcs1::{DecodeRsaPrivateKey, DecodeRsaPublicKey},
    traits::PublicKeyParts,
 };
+use ed25519_dalek::SigningKey;


Import as Ed25519SigningKey

arckoor · 2026-06-18T13:30:30Z

+// --- EllipticCurve Constants ---
+// Key Lengths
+// ED25519: https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.5
+pub(crate) const ED25519_PUBLIC_KEY_LENGTH: usize = 32;
+// ED448: https://datatracker.ietf.org/doc/html/rfc8032#section-5.2.5
+pub(crate) const ED448_PUBLIC_KEY_LENGTH: usize = 57;


ok to inline

arckoor · 2026-06-18T13:31:26Z

 }

-pub struct EdDSAVerifier(VerifyingKey);
+pub struct EdDSAVerifier(pub VerifyingKey);


richy1623 · 2026-06-19T16:57:43Z

@arckoor I'm made the changes and added a test case for extracting the PEM key which now fails as expected 👍

arckoor · 2026-06-19T21:32:48Z

Sorry, I should have been clearer, I meant to remove the 448 stuff entirely
It doesn't really hurt to have it, but including a code path that can exclusively be reached by using the from_der methods with an unsupported key just seems kind of silly

ed_pub_components_from_public_key is just entirely superfluous I think? If you inline the the length check to from_decoding_key as well

The 448 test is good to keep though

richy1623 · 2026-06-20T11:50:21Z

@arckoor I have removed all Ed448 references now (keeping the test). Let me know if there is anything else you would like me to change.

arckoor

Thanks!

arckoor · 2026-06-20T16:52:57Z

+                    let (curve_type, x) = match &key.kind() {
+                        DecodingKeyKind::SecretOrDer(pub_bytes) => {
+                            match pub_bytes.len() {
+                                // ED25519: https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.5
+                                32 => (EllipticCurve::Ed25519, pub_bytes),
+                                _ => return Err(ErrorKind::InvalidEddsaKey.into()),
+                            }
+                        }
+                        _ => return Err(ErrorKind::InvalidKeyFormat.into()),
+                    };


In #515 should be able to use try_get_as_bytes (just note to self so I don't forget :p)

Keats · 2026-07-23T12:36:33Z

+                    // Note: here we will receive a DER key which contains a 16 byte ANS.1 header
+                    let curve_type: EllipticCurve = match key.inner().len() {
+                        // 16 byte header + 32 byte Ed25519 key
+                        48 => Ok(EllipticCurve::Ed25519),


do we need that check @arckoor? That's going to error for v2 eg aws-lc-rs::Ed25519KeyPair::generate_pkcs8 (unless it's handled somewhere else/am misusing it)

I mean yeah, but isn't this actually the job of PemEncodedKey? For the from_der methods, users are currently just required to pass the "correct" key format, but for PEM we do a fair amount of parsing. For public keys we at least try to extract the public key bytes from whatever wrapper there is, for private keys we just use the inner content. E.g. this breaks completely

use aws_lc_rs::signature::Ed25519KeyPair; use jsonwebtoken::{Algorithm, EncodingKey, jwk::Jwk}; fn main() { let rng = aws_lc_rs::rand::SystemRandom::new(); let pkcs8 = Ed25519KeyPair::generate_pkcs8(&rng).unwrap(); let pem = pem::encode(&pem::Pem::new("PRIVATE KEY", pkcs8.as_ref().to_vec())); let encoding_key = EncodingKey::from_ed_pem(pem.as_bytes()).unwrap(); Jwk::from_encoding_key(&encoding_key, Algorithm::EdDSA).unwrap(); // panics, len 83 }

IMO EncodingKey and DecodingKey should convert any incoming key into a format that the rest of the library can use. If that is done properly, checks like this can just be omitted everywhere.
I have toyed with the idea of replacing simple_asn1 with der (for zero alloc parsing, which would remove the zeroizing troubles from PemEncodedKey entirely)
With that done I'd also like to refactor the from_der methods to actually accept proper DER encodings, so accepting V2 could be done there as well

Honestly it would be nice if people didn't have to know what they are using (is it der? is it pcks v1? maybe v2? pem?) and we just look at the format to infer the type of keys.

Yes, EncodingKey::new(bytes: &[u8], alg: Algorithm) would be very neat to have I think
Would perhaps still need an extra distinction like we have now for HMAC, but for the asymmetric stuff it should definitely be possible

Yep, something like that was exactly was I was thinking

Feat: Added support for JWK decoding Ed25519 keys

56f02f6

arckoor added the Breaking label Apr 28, 2026

added some basis for ed488

3a26212

richy1623 marked this pull request as ready for review April 28, 2026 11:29

wasm test import fix

f946deb

arckoor self-requested a review May 29, 2026 22:28

arckoor mentioned this pull request May 30, 2026

Conversion between Algorithm and KeyAlgorithm #513

Closed

arckoor requested changes May 30, 2026

View reviewed changes

Comment thread src/crypto/aws_lc/eddsa.rs Outdated

Comment thread src/crypto/mod.rs Outdated

Comment thread src/jwk.rs

Comment thread tests/eddsa/mod.rs Outdated

richy1623 added 5 commits June 14, 2026 09:18

Merge branch 'master' of github.com:Keats/jsonwebtoken into feat/jwk_…

8533706

…decode_ed25519

resolved more of the merge issues

d44949a

correction

7d2e74a

Review changes

ab6da44

Non-exhasutive curves

60d4df1

richy1623 commented Jun 14, 2026

View reviewed changes

Comment thread src/jwk.rs

richy1623 requested a review from arckoor June 14, 2026 11:48

Added ans1 as a dep

0a16e3e

arckoor mentioned this pull request Jun 15, 2026

Flattening extra fields in Header errors on non-string extra fields #510

Closed

arckoor requested changes Jun 18, 2026

View reviewed changes

richy1623 added 2 commits June 19, 2026 18:34

review changes

fa50ec0

Removed the ability to extract Ed448 from a PEM

a088a7a

richy1623 requested a review from arckoor June 19, 2026 16:56

Added a warning to the decode method

25357a3

Removed all Ed448 references

0f411c9

arckoor approved these changes Jun 20, 2026

View reviewed changes

arckoor merged commit 31a1dc6 into Keats:master Jun 20, 2026
10 checks passed

arckoor mentioned this pull request Jun 30, 2026

Release 11.0.0 #523

Closed

Keats reviewed Jul 23, 2026

View reviewed changes

arckoor mentioned this pull request Jul 24, 2026

Allow deserializing unknown key type JWKs #530

Merged

Conversation

richy1623 commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

richy1623 commented Jun 14, 2026

Uh oh!

arckoor left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

richy1623 commented Jun 19, 2026

Uh oh!

arckoor commented Jun 19, 2026

Uh oh!

richy1623 commented Jun 20, 2026

Uh oh!

arckoor left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

richy1623 commented Apr 28, 2026 •

edited

Loading