-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding CORECLR Cross-Platform support to ECDH-ES #232
Adding CORECLR Cross-Platform support to ECDH-ES #232
Conversation
… method supports both ECDiffieHellman and ECDsa.
Adding back the supported frameworks to the project's properties.
Hi @digaomatias , thanks for PR ! Well, i would say backward compatibility is important thing. Give me sometime to wrap my head around changes next week and i'll get back to you with questions. |
Hey @digaomatias , did first pass over commit, left couple comments here & there. In general i'd split Will be cleaner code wise and will preserve existing contract for library. Library already supports multiple key types almost everywhere, so having BTW, how you envision to load |
Hey mate, I really like the ideas!
It will take me a bit longer to get all that lined up. I'll see if i can
get all that by the end of this week or the next.
Regarding how I envision to load ECDiffieHellman: in our particular
scenario, we have the keys stored in a Cloud Secrets Manager as plain
JsonObjects.
The keys are loaded by our application as needed from the secrets manager.
From there we just deserialize into a JsonWebKeys object and map the X,Y,D
parameters into the ECDiffieHellman.Create.
But creating from a PEM file should work fine as well. Here's what I found:
Here's a general outline of the steps involved:
1. Read the PEM file and extract the base64-encoded portion.
2. Decode the base64 content to get the ASN.1 DER-encoded key.
3. Parse the DER encoding to get the key parameters.
4. Create an ECDiffieHellman object using the extracted key parameters.
…On Tue, Sep 26, 2023 at 2:41 AM DV ***@***.***> wrote:
Hey @digaomatias <https://github.com/digaomatias> , did first pass over
commit, left couple comments here & there.
In general i'd split EcdhKeyManagement.cs into EcdhKeyManagementWin.cs &
EcdhKeyManagementRest.cs and register appropriate implementation inside
https://github.com/dvsekhvalnov/jose-jwt/blob/master/jose-jwt/JWTSettings.cs#L88C41
based on something like
RuntimeInformation.IsOSPlatform(OSPlatform.Windows)
Will be cleaner code wise and will preserve existing contract for library.
Library already supports multiple key types almost everywhere, so having
CngKey (plus probably additionally ECDiffieHellman) on windows and
ECDiffieHellman on linux for some key management algos - sounds just fine.
BTW, how you envision to load ECDiffieHellman in real life? Typically key
is a file on disk (.pem, e.t.c.) or stores in OS keystore?
—
Reply to this email directly, view it on GitHub
<#232 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJZX6PXODQVFU764YS3UTX4GC2DANCNFSM6AAAAAA5AVNFFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
--
Abraço!
Rodrigo Matias Leote
.NET Developer
"Whatever the mind can conceive and believe, the mind can achieve." - Dr.
Napoleon Hill
|
@digaomatias if you short on time, i can probably pick up your work and adjust, let me know. |
Added a TestSuiteUnix.cs file containing the Unix execution flow. Changed the TestSuite.cs to make the tests skippable if it's runninf on non-Windows platforms. Changed JWTSettings to load the proper ECDH strategy based on the OSPlatform.
Hey @dvsekhvalnov |
Yeah, no worries, i totally get what it mean to be busy :) have your time. |
|
||
namespace Jose | ||
{ | ||
public class EcdhKeyManagementWinWithAesKeyWrap : EcdhKeyManagementUnix |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should fix a couple of your tests.
public class EcdhKeyManagementWinWithAesKeyWrap : EcdhKeyManagementUnix | |
public class EcdhKeyManagementWinWithAesKeyWrap : EcdhKeyManagementWin |
@digaomatias if you need any help implementing this let me know what I can do. |
@digaomatias sorry to bother you, but have you had any time to look at this or will you have time soon? If not, could one of the people who offered to help pick it up? I am hoping to use the non-Windows support very soon in a project I am working on. Thanks for the contribution! |
Good news, I just pushed the rest of the changes. Now we need to wait for @dvsekhvalnov approval :) |
Thanks, i'll take a look next week. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were there any real changes in the file? Sounds like formatting only (though i can't even figure out a difference)?
if (jwk.Kty == Jwk.KeyTypes.EC) | ||
{ | ||
privateKey = jwk.EcDiffieHellmanKey(); | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not checking for ECDsa
? Missing symmetry with wrap
flow.
{ | ||
throw new JoseException("(Direct) ECDH-ES key management cannot use existing CEK."); | ||
} | ||
|
||
private byte[] NewKey(int keyLength, object key, IDictionary<string, object> header) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds like the only differentiator here is OS: Win vs Everything else? We can't branch based on key type (CngKey
vs ECDiffieHellman
) because JWK
hiding actual implementation?
jose-jwt/crypto/ConcatKDF.cs
Outdated
#endif | ||
} | ||
|
||
public static byte[] DeriveKeyNonCng(ECDiffieHellman externalPubKey, ECDiffieHellman privateKey, int keyBitLength, byte[] algorithmId, byte[] partyVInfo, byte[] partyUInfo, byte[] suppPubInfo) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
funny name :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hahaha true. I'll change to make it more explicit, like DeriveEcdhKey
jose-jwt/keys/EccKey.cs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, any functional changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It used to have changes, but it was reverted.
We can discard it.
UnitTests/TestSuiteUnix.cs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can't we somehow have single TestSuite.cs
(e.g. not splited by OS type) leveraging xUnit conditions?
Something like: https://josephwoodward.co.uk/2019/01/skipping-xunit-tests-based-on-runtime-conditions
Maintaining 2 suites by 250+ tests quite challenging.
UnitTests/jwk/JwkUnixTest.cs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as with TestSuite.cs
. Can we collapse JwkTest.cs
and JwkUnixTest.cs
into JwkTest.cs
with xUnit conditions?
UnitTests/jwe/JweUnixTest.cs
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same comment as with TestSuite.cs
. Can we collapse JweTest.cs
and JweUnixTest.cs
into JweTest.cs
with xUnit conditions?
Hey guys, i've added some comments. In general i'm fine with a change, my only real concern is duplicating unit tests, it's quite challenging to maintain, will appreciate if we can use some xUnit magic to avoid it. Once we good, i'll run cross compatibility tests with some other libraries and prepare release. |
Anything I can do to help move this along? |
hi @digaomatias , i think we need to ping @digaomatias :) I just don't know if he is planning to work on comments or if we can pick up where he left to finalize. Sometimes open source is confusing is that regard. |
Sorry guys, my work got extremely busy these last few days and I couldn’t
work on it. And probably won’t have time to do it for the next week at
least.
If you want to pick it up I’m fine with that. Otherwise I would be able to
continue the work in one week roughly.
Thanks for understanding.
…On Tue, 21 Nov 2023 at 10:42 PM, DV ***@***.***> wrote:
hi @digaomatias <https://github.com/digaomatias> , i think we need to
ping @digaomatias <https://github.com/digaomatias> :)
I just don't know if he is planning to work on comments or if we can pick
up where he left to finalize. Sometimes open source is confusing is that
regard.
—
Reply to this email directly, view it on GitHub
<#232 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJZX32L37STW72RVW6MG3YFRZQPAVCNFSM6AAAAAA5AVNFFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMRQGU3DINJSGQ>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
All right guys, sorry for the long delay. New year's January resolution is to finish this! 👯 |
…CDH and CngKey test runs on windows, where test will run only with ECDH on Unix. Resolving other PR Comments.
I've finished working on the changes for the PR comments. If the unit tests work well on the Unix, it should be good to go. |
…W AES-CBC JWK unit tests
✅ Win NetFX cross compatibility tests |
✅ OSX NetCore cross compatibility tests 2 more to go :) |
✅ Linux NetCore cross compatibility tests |
✅ FreeBSD NetCore cross compatibility tests |
Okay, it looks amazing, definitely worth version 5 :) Just docs update and we good to go. |
While we are here, does anybody have feeling library need helpers to load all kinds of keys from common file formats, like It's relatively trivial but some gotchas here and there if you want to export private parts, e.t.c. Something like: ECDsa pk = EcdhKey.LoadPrivate("my.p12", "password"); |
Ok, i think that's it. About to merge it now :) Want to say huge thank you to @polewskm and @digaomatias for great idea and bringing it to live. That's fixing 10yo compatibility issues with Microsoft ncrypt.dll and making library fully compliant on all major operating systems. Truly amazing. Before we close it off, some stats: was around 70 commits and 6K lines changed, which is not an small fix by all means :) P.S> Gonna release it soonish to nuget along with #237 (should be quick 🤞), as you know zero tolerance to security issues ;) |
great job guys. Thank you very much |
Amazing work! Well done!
Abraço!
Rodrigo Matias Leote
.NET Developer
"Whatever the mind can conceive and believe, the mind can achieve." - Dr.
Napoleon Hill
…On Mon, 18 Mar 2024 at 10:17 PM, lucabarbi ***@***.***> wrote:
great job guys
—
Reply to this email directly, view it on GitHub
<#232 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABJZX2WC4YTTOBZLRSB4YTYY2WJLAVCNFSM6AAAAAA5AVNFFWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBTGI4DMMZRHA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
v5.0.0 released to nuget.org For those who in air gapped environments copy uploaded: https://github.com/dvsekhvalnov/jose-jwt/releases/tag/v5.0.0 |
Changing the code to make it .NET Core compatible cross-platform now supporting:
The main reason why these algorithms were not supported cross platform on CORECLR was because it makes use of CngKey, which is Windows specific. The main place where this type is required is very downstream when using ConcatKDF.DeriveKey.
I've followed the instructions from the user polewskm, where he specified on this issue:
I've created a new method on ConcatKDF named DeriveKeyNonCng. It gets an ECDiffieHellman key instead of a CngKey.
Because of that, I had to modify everything upstream to use and work with ECDiffieHellman instead of CngKey.
The points of question on this PR are:
If you think we need to support CngKey and go for the dual path option, I can't promise a PR in a timely manner, because I have to focus on my work here, and our needs are resolved with the ECDiffieHellman only path.