Support for EdDSA

[augustocdias]

Do you have any plans to support EdDSA algorithm?

Could you describe what needs to be done for it so maybe we can create a PR?

[Keats]

It's already in https://github.com/Keats/jsonwebtoken/pull/160 ! The v8 needs some help making it easier to create Encoding/Decoding keys

[augustocdias]

You mean this?

let privkey = include_bytes!("private_ed25519_key.pk8");
let pubkey = include_bytes!("public_ed25519_key.pk8");

[Keats]

Not exactly, get https://docs.rs/jsonwebtoken/7.2.0/jsonwebtoken/struct.DecodingKey.html and https://docs.rs/jsonwebtoken/7.2.0/jsonwebtoken/struct.EncodingKey.html work better. The idea is that parsing will only be done once in the app instead of each time you use a JWT like you would with include_bytes!

[augustocdias]

Excuse me if I didn't get it right, but this seems unrelated to the eddsa support and related to a more high level API that would affect all algorithms... Is that right?

[Keats]

Yep, there's already a version in v7 but it's not ideal

[augustocdias]

I still didn't get what is wrong with them. All the functions take those keys as non mutable references. They can be easily shared between calls. Could you elaborate more your idea, so maybe I could contribute?

[Keats]

See https://github.com/Keats/jsonwebtoken/issues/120

[augustocdias]

Okay. I got it now. I want to help on this as the project I'm working on will need this too. The idea is to remove the underlying Cow in the keys and always own the key's content?

[Keats]

Probably but it would be nice to have all users currently running into that issue together to fix everything. It's already going to be v8 and any change there will be breaking

[augustocdias]

It doesn't have to be breaking. Keeping the method signatures and just cloning the parameters to own the values should work just fine and wouldn't break the API. I'm sure it can be improved, but it could be step into deprecation instead of breaking.

The only breaking thing I see is the into_static that doesn't make sense anymore.

And I suppose this problem affects only the DecodingKey right?

[tiptenbrink]

Hi @Keats, I'm trying this out on the next branch, but I am unable to load Ed448 keys from PEM using EncodingKey. I'm generating a fresh set of keys using OpenSSL. I also saw that there are currently no tests for EdDSA, yet, so I'm not sure if maybe I'm missing something.

Ed25519 works fine but ed448 does not work.

    #[test]
    fn test_token() {
        let at = AccessToken {
            sub: "ab".to_string()
        };
        let ed25519 = "-----BEGIN PRIVATE KEY-----
            MC4CAQAwBQYDK2VwBCIEIHZ4+VqCXpwjjlv439/zsrKHcWJej0ZgJt4XaJ7Lxd8/
            -----END PRIVATE KEY-----".to_string();
        let ed448 = "-----BEGIN PRIVATE KEY-----
            MEcCAQAwBQYDK2VxBDsEOV8K6nOltf9IEE+xHw7HY9bwrPyjEu3+RHYMMEgS6QTJ
            w1dLURYlIrYYxX9N52B5n/U2aF1owL0xDg==
            -----END PRIVATE KEY-----".to_string();
        // Change ed448 to ed25519 and it works
        let encoding_key = EncodingKey::from_ed_pem(ed448.as_bytes()).unwrap();
    }

This fails with Error(InvalidKeyFormat). Since the InvalidKeyFormat Error does not indicate where the error occurs, I'm having a hard time debugging, so help would be appreciated. Looking at the code I do not see a specific reason why ed448 would not work vs ed25519.

Thanks for this library!

[Keats]

This is likely the line failing: https://github.com/Keats/jsonwebtoken/blob/next/src/pem/decoder.rs#L151 or https://github.com/Keats/jsonwebtoken/blob/next/src/pem/decoder.rs#L154 Basically something went wrong when decoding the PEM. Could it be in PKCS1 instead of PKCS8?

[tiptenbrink]

This is likely the line failing: https://github.com/Keats/jsonwebtoken/blob/next/src/pem/decoder.rs#L151 or https://github.com/Keats/jsonwebtoken/blob/next/src/pem/decoder.rs#L154 Basically something went wrong when decoding the PEM. Could it be in PKCS1 instead of PKCS8?

No I'm very certain it is pkcs8. I tried it on a key I'm using in a Python library that assumes it's pkcs8 and it's working there. The key above was generated using:

openssl genpkey -algorithm ED448 -out private448.pem
openssl pkcs8 -in private448.pem -nocrypt

[tiptenbrink]

My apologies, I think you can close this. I discovered there's a reason Ed448 keys don't work as mentioned in #154: ring does not have support for it (briansmith/ring#463).

[Keats]

Ah sorry, completely forgot about that!