-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
ChaCha20Poly1305.IsSupported always returns false on non-Windows #52482
Comments
Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks Issue DetailsFollow-up to #45130. We checked in an implementation of ChaCha20Poly1305 for Windows, but we don't have one for Mac / Linux scenarios. This work item tracks calling in to the existing CryptoKit / OpenSSL implementation for Mac / Linux scenarios so that we don't forget to do this work. Marked up for grabs.
|
It looks like ChaCha20Poly1305 is also available on Android for newer API levels, so it might be worth considering conditionally providing an implementation there as well. |
@bartonjs what is your feeling on waiting for OpenSSL 3.0 work to be done? Do you think much or any work in this area would be impacted by it? |
No concerns. Since we now work with OSSL3 using both direct and portable builds everything else is just preemptive cleanup (e.g. get wholly onto EVP_PKEY), which is why the effort got slightly backburnered. |
I started a proof of concept of the CryptoKit part (https://github.com/dotnet/runtime/compare/main...filipnavara:cryptokit?expand=1) but it's huge fight with CMake and Apple tools so far. |
@filipnavara instead of discovering the Swift toolchain on your own, you can try adding an |
@jkoritzinsky Unfortunately it's only supported on Ninja and Xcode, not on Unix makefiles. Even on Ninja it doesn't quite mix well with other languages. I am still evaluating how to improve the situation for static libraries consumed by apphost and Xamarin. |
That sucks. Can you make sure to include a comment in the file that discovers the Swift tool chain explaining that so we know when looking back why we manually discover? |
Sure. I don't even know if I will be able to make it work reliably for all use cases yet. I am trying different approaches and this was just first one that got far enough to produce some visible results. |
I updated the issue text with a bunch of check boxes for the various OSes. That way we can do the PRs piecemeal if that'd be easier. If I missed any OS please feel free to update the issue text directly. |
@filipnavara you've gotten much further than I have, I think you found my branch (there are a couple) so feel free to take any scraps of code there that are helpful. OpenSSL seems straight forward, so I will tackle that this afternoon. |
Sure enough the approach I took was fundamentally broken :-) The stable Swift runtime is only shipped on iOS 12.2+ and macOS 10.14.4+. Lot of the hacks from the CMake script are unnecessary when explicitly targeting newer versions. It would not work on downlevel platforms though and my hacked version doesn't work either. It quite easy to solve for the case with dynamic libraries but it's much more tricky for the static libraries. I will try to play a bit with weak linking to see if I can get something running. Not sure whether the dynamic-only version would be worth the trouble, especially since it cannot be used on iOS [where OpenSSL is not available]. |
I'm leaning towards abandoning the CryptoKit experiment. The last version is available at https://github.com/dotnet/runtime/compare/main...filipnavara:cryptokit?expand=1. It enables the weak linking of Swift runtime and the library loads on down-level platforms to the extent that graceful fallback is possible in the managed code. However, there are few reasons why I think it's not worth the trouble:
For additional reference I also included experiment with using Apple private CommonCrypto APIs which has different drawbacks:
|
Thanks again for your very deep research in to this. Unfortunate that CryptoKit is problematic in the static linking scenario.
Hm. Yeah that would be a breaking change for folks that are using it just fine on a Mac with OpenSSL. Though 128 bit tags is by far the most common tag size used. We know what tag size should be used at invocation time, we could just fall back to OpenSSL again if they are requesting or using a tag length that is not 128 bits.
I'm having trouble finding the issue in which this was discussed, but the conclusion then was that we could not use the private APIs (even if they are "documented" at open source.apple.com) The main issue I am seeing then is with static linking and CryptoKit. |
The static linking scenario is a solvable one even if it requires some cooperation on the Xamarin side. Ideally we would need to embed the necessary linker flags in some way in the runtime NuGet consumed by Xamarin and implement a way to use them there. It's non-trivial but very much doable and possibly there are other scenarios where this would be useful (cc @rolfbjarne). UPD: It would be pretty trivial to put a static file in the NuGet and read it here and append it all to
We could do that but at the moment I am slightly tipped on the benefits/drawbacks scale towards not doing that. However, on platforms like iOS where OpenSSL is not available a limited implementation may be a tiny bit better than no implementation at all.
It's a slippery slope here. I did the experiment only to see if it could be done but I don't think that is a code that should be included in the .NET runtime. There's anecdotal evidence that Apple doesn't reject apps using these APIs in app store reviews but that's likely not good enough. The only good thing about the approach is that it's super simple and it can be linked out by the managed linker. I am considering wrapping this part in a C# library and just publishing it as NuGet. |
In an effort to learn something new, I thought I would give the Android implementation a shot. Looks like there are at least some existing patterns I can follow for lighting-up functionality depending on the API Level (28+ for ChaCha20Poly1305). |
If you have any questions on it, let me know and I can probably help out. |
It seems the issue can be closed. |
This is still tracking iOS/tvOS support for ChaCha20Poly1305 which currently has some blockers in to implement. |
I have this problem on Window 10. Below are details: |
@PiotrKowalski93 your Windows version is too old, the algorithm is only supported in 10.0.20142 and later (see #45130) |
Follow-up to #45130. We checked in an implementation of ChaCha20Poly1305 for Windows, but we don't have one for Mac / Linux scenarios.
This work item tracks calling in to the existing CryptoKit / OpenSSL implementation for Mac / Linux scenarios so that we don't forget to do this work.
Implementations needed for:
Marked up for grabs.
The text was updated successfully, but these errors were encountered: