enable ES256K for ECDSA signing scheme

[pohutukawa]

Ethereum, Bitcoin (and uPort) use the secp256k1 curve for their signature scheme. To allow for JWT (and other JOSE schemes) handling in uPort, the ES256K algorithm has been added.

Additionally, requirements-dev.txt contained a redundant entry ecdsa causing a pip install to fail due to it being already listed in the chained requirements.txt.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 96.56%. Comparing base (e31416a) to head (35fb5b8).
Report is 162 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #113   +/-   ##
=======================================
  Coverage   96.55%   96.56%           
=======================================
  Files          14       14           
  Lines        1075     1076    +1     
=======================================
+ Hits         1038     1039    +1     
  Misses         37       37           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pohutukawa]

Ping. Any insights on whether this might make it into python-jose or whether there's something I can do to make it suitable?

[wbobeirne]

I can confirm that this worked perfectly for my use-case (Decoding Blockstack JWTs, as they use ES256K encoding.) Would love to see this merged!

[pohutukawa]

I've just fixed up a minor merge conflict that's crept in due to this thing being a bit stale.

[zejn]

Thanks for refreshing this PR!

I think this would be a welcome functionality to have in python-jose.

I did a quick review, the functionality generally looks good. There's an issue in the ecdsa backend with the hash function implicitly specifying the curve to be used, so current PR can only use P-256K when using ecdsa backend. This should probably be turned around, similarly to the way it's implemented in cryptography backend, so the hash function depends on the curve.

Please also add an entry to the change log now that we have it and reference this PR.

This will need more tests to be more maintainable over the long term. Current tests didn't find the issue with ecdsa backend, flake8 test did, so there's a blind spot somewhere. It would probably be best if the existing EC tests could be parametrized to run with both P-256 and P-256K keys, see how the pytest.mark.parametrize decorator works in other test cases. Tests will also have to check how the library behaves when supplying a P-256 key and choosing P-256K algorithm and reverse, this should probably throw an error.

If you are unsure on any approach, need help, or more time, say so. I'm here to help this make a good contribution and hopefully break as little existing usages as possible.

[zejn]

Key in line 29 is same as key in line 26, that's a bug.

[blag]

@pohutukawa Please fix.

[blag]

A few nitpicks to take care of, and one bug to fix.

[blag]

Nitpick: I'm a huge fan of trailing commas in lists to minimize the size of diffs (and also makes git blames a lot more easier). Please add a trailing comma to the ALGORITHMS.E256K line.

[blag]

@pohutukawa Please fix.

[blag]

Trailing comma here as well.

[twwildey]

Can you rebase your changes onto the latest master branch and force-update your branch for this PR?

[reisepass]

would be nice to get this in :) pyJWT added it https://github.com/jpadilla/pyjwt/blob/29fbfc36d95f3df41bc9650b6711347549829bf3/jwt/algorithms.py#L31 and JoseRFC added it https://github.com/authlib/joserfc but then they don;t allow it for JWS for some reason

[lepture]

@reisepass joserfc allows using ES256K for JWS. Since this algorithm is not recommended by default, you need to manually enable it by passing algorithms=['ES256K'] parameter.

1. https://jose.authlib.org/en/guide/algorithms/#json-web-signature
2. https://jose.authlib.org/en/guide/jws/#unsupportedalgorithmerror