-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[iOS] Implement DSA, RSA, EC key import/export #51926
Conversation
Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks |
ecda3e2
to
63d21b7
Compare
63d21b7
to
d68afd6
Compare
@bartonjs Now that the other PRs have been merged I suppose this is good enough for first round of review. It's the major remaining change that enables S.S.C.Algorithms to work on iOS. (I am on different time zone so I try to keep few PRs open during my rest time to speed up the feedback process.) |
...es/Common/src/Interop/OSX/System.Security.Cryptography.Native.Apple/Interop.SecKeyRef.iOS.cs
Outdated
Show resolved
Hide resolved
src/libraries/Common/src/System/Security/Cryptography/DSASecurityTransforms.cs
Show resolved
Hide resolved
src/libraries/Common/src/System/Security/Cryptography/DSASecurityTransforms.macOS.cs
Show resolved
Hide resolved
src/libraries/Common/src/System/Security/Cryptography/RSASecurityTransforms.macOS.cs
Outdated
Show resolved
Hide resolved
@@ -139,3 +139,82 @@ uint64_t AppleCryptoNative_SecKeyGetSimpleKeySizeInBytes(SecKeyRef publicKey) | |||
|
|||
return SecKeyGetBlockSize(publicKey); | |||
} | |||
|
|||
#if defined(TARGET_MACCATALYST) || defined(TARGET_IOS) || defined(TARGET_TVOS) |
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.
Does this need to be conditional?
- No: Great, let's remove the ifs
- Yes, this uses API not on macOS: Sadface.
- Yes, this is alternative implementations of functions already present for macOS: Can we get rid of all of these triple target references and use one or two high-level defines based on these? (e.g. FULL_MACOS and MOBILE_MACOS, or some names that get more than 3 seconds of thought)
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 doesn't have to be conditional. It's just not used on macOS yet in this PR which is why I excluded it. I'd be happy to remove the conditionals and add the references to entrypoints.c
. I prototyped a managed implementation that uses both types of the keys (iOS / CSSM) on macOS but I don't intend to submit it as PR (at least not until the the iOS part is working).
Generally I would prefer to split the iOS / macOS code into different files in the native dylib but I didn't do it because of the preexisting code. I do think it would make sense though, especially with support for iOS keychain which is substantially different from the macOS one. Most of the #if
s would be removed and appear only once in the CMake script that way.
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.
Yeah, I guess for me it's "is this only for iOS" vs "is this only for iOS today". If future PRs (particularly in this release) are going to start calling these functions from macOS, the API shouldn't be conditional.
And if the API is conditional, I agree that I'd prefer the isolation be done at the file level.
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.
I guess it is iOS only today so I'll just include these new APIs unconditionally.
And if the API is conditional, I agree that I'd prefer the isolation be done at the file level.
If I get to do the iOS keychain work I'll introduce that pattern.
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.
I've opened #51976 to get CI run for the implementation of data keys on macOS. I suspect it will need some tweaking but given how much code I'd move back and forth it would likely make sense to merge it into this PR if I can get the CI to pass.
src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/pal_seckey.c
Show resolved
Hide resolved
src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/pal_seckey.c
Outdated
Show resolved
Hide resolved
src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/pal_seckey.c
Outdated
Show resolved
Hide resolved
...s/System.Security.Cryptography.Algorithms/src/System.Security.Cryptography.Algorithms.csproj
Show resolved
Hide resolved
...braries/System.Security.Cryptography.Algorithms/tests/DefaultECDiffieHellmanProvider.Unix.cs
Outdated
Show resolved
Hide resolved
src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/pal_seckey.c
Show resolved
Hide resolved
src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/pal_seckey.c
Show resolved
Hide resolved
Thank you for the contribution. |
No description provided.