ES256 errors with InvalidEcdsaKey

[eighty4]

Deep down in ring::io::der::expect_tag_and_get_value I always get an error bubbling up to an InvalidEcdsaKey. I think my brain melted trying to figure out the problem.

This is how I'm generating keys:

openssl ecparam -name secp256k1 -genkey -noout -out private.sec1.pem
openssl ec -in private.sec1.pem -pubout > public.pem
openssl pkcs8 -topk8 -nocrypt -in private.sec1.pem -out private.pkcs.pem

Here's the private key:

openssl asn1parse -i -in private.sec1.pem
    0:d=0  hl=2 l= 116 cons: SEQUENCE
    2:d=1  hl=2 l=   1 prim:  INTEGER           :01
    5:d=1  hl=2 l=  32 prim:  OCTET STRING      [HEX DUMP]:311AF2663D9B22B553BD72E1960640D8586C4A7D6CBA2B1915F8988E1FE0DFDF
   39:d=1  hl=2 l=   7 cons:  cont [ 0 ]
   41:d=2  hl=2 l=   5 prim:   OBJECT            :secp256k1
   48:d=1  hl=2 l=  68 cons:  cont [ 1 ]
   50:d=2  hl=2 l=  66 prim:   BIT STRING

Here's the key you use in tests:

openssl asn1parse -i -in tests.pem
    0:d=0  hl=3 l= 135 cons: SEQUENCE
    3:d=1  hl=2 l=   1 prim:  INTEGER           :00
    6:d=1  hl=2 l=  19 cons:  SEQUENCE
    8:d=2  hl=2 l=   7 prim:   OBJECT            :id-ecPublicKey
   17:d=2  hl=2 l=   8 prim:   OBJECT            :prime256v1
   27:d=1  hl=2 l= 109 prim:  OCTET STRING      [HEX DUMP]:306B020101042059315F08696363A6B0DC7AED90798F4626B3BA4C4F2DBEA29694407B08D6F278A14403420004C3B240A14FE025B649BD5FB308EBD4F72149AB414D0BF79D08C44CEFC3FC7904C10835132B5CB04986ACCEF419BE77A25BA80DB561099DD4AB784732C94755BE

I adapted your test and ran the test using the same curve your key uses and the curve I used based on a guide on Akamai and the test worked once I switched to prime256v1. I started typing this issue after an hour of debugging but found the fix while collecting all the details. Is there a reason one curve would work but not another? With the right info I'd like to document it so it doesn't trip up someone else.

[Keats]

Maybe our pem decoder (https://github.com/Keats/jsonwebtoken/blob/master/src/pem/decoder.rs) doesn't work well in some cases? I don't know, I haven't touched that part in years

[EvilWatermelon]

I have a similiar problem with the error message Error(InvalidKeyFormat)

I found this function with the comment:

/// Can only be PKCS8
    pub fn as_ec_public_key(&self) -> Result<&[u8]> {
        match self.standard {
            Standard::Pkcs1 => Err(ErrorKind::InvalidKeyFormat.into()),
            Standard::Pkcs8 => match self.pem_type {
                PemType::EcPublic => extract_first_bitstring(&self.asn1),
                _ => Err(ErrorKind::InvalidKeyFormat.into()),
            },
        }
    }

As far as I know I can't convert a ec public key to the pkcs8 format. This seems to be a bug?

[delbonis]

I believe I'm having a similar issue. I'm following basically the exact same steps as the above but the library is telling me InvalidEcdsaKey when I try to sign a token. Did OpenSSL change the structure recently and now it's breaking the decoder?

[p-lindberg]

I tried to use an ECDSA key generated by pulumi's privatekey resource and couldn't get it to work. Then I found that the library refuses to parse ECDSA keys in the PKCS#1 format, which apparently is what pulumi generates, as far as I understand it. There's this comment in the code:

// No "EC PRIVATE KEY"
// https://security.stackexchange.com/questions/84327/converting-ecc-private-key-to-pkcs1-format
// "there is no such thing as a "PKCS#1 format" for elliptic curve (EC) keys"

As I understand it, the PKCS#1 format was meant exclusively for RSA keys, and the library author has therefore decided not to support it for ECDSA keys. At the same time, I was able to parse the same key in .NET with no issues, so it seems that at least some other libraries/frameworks allow this format to be used for ECDSA keys.

Given that this format appears to be used for ECDSA keys out in the wild, and that other libraries support it, wouldn't it make sense to support it in jsonwebtoken as well?

[eighty4]

@p-lindberg that sounds like a separate issue. My error was fixed by changing the elliptic curve and not the container.