Changing the code to make it .NET Core compatible cross-platform now supporting:
ECDH-ES* with A128CBC-HS256, A128GCM, A192GCM, A256GCM
ECDH-ES+A128KW*, ECDH-ES+A192KW*, ECDH-ES+A256KW* with A128CBC-HS256, A128GCM, A192GCM, A256GCM
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:
- Refactor your ConcatKDF.DeriveKey to NOT use ECDiffieHellmanCng (notice the ...Cng suffix here)
- There is no equivalent implementation of SP800_56A_CONCAT in Linux
- You have to implement the functionality of SP800_56A_CONCAT yourself
- That is what my snippet is showing, how to manually implement SP800_56A_CONCAT on Linux using ECDiffieHellman (notice that lack of ...Cng in the suffix here)
- ...Cng classes cannot be used on Linux as they are Windows only
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:
Do we still need to support CngKey or can we make it a breaking change for newer versions of the library?
If we do need support to CngKey, I would have to change this PR to have two versions of all the Elliptic Key flows, one that follows the CngKey path down to the ConcatKDF.DeriveKey, and another that follows the ECDiffieHellman path, that follows the path down to the ConcatKDF.DeriveKeyNonCng.
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.
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.