ChaCha20Poly1305.IsSupported always returns false on non-Windows

[GrabYourPitchforks]

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:

• Unix (Support ChaCha20 Poly1305 on Unix #52522)
• Android (Support ChaChaPoly1305 on Android if available #52814)
• iOS
• Mac OS (Implement ChaCha20Poly1305 with CryptoKit on macOS #76317)

Marked up for grabs.

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq, @GrabYourPitchforks
See info in area-owners.md if you want to be subscribed.

Issue Details

---

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.

Marked up for grabs.

Author:	GrabYourPitchforks
Assignees:	-
Labels:	area-System.Security, up-for-grabs
Milestone:	-

[jkoritzinsky]

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.

[vcsjones]

@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?

[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.

[filipnavara]

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.

[jkoritzinsky]

@filipnavara instead of discovering the Swift toolchain on your own, you can try adding an enable_language(Swift) line in the CMakeLists.txt file. I think we use a new enough CMake on Mac that Swift support is built-in.

[filipnavara]

@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.

[jkoritzinsky]

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?

[filipnavara]

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.

[GrabYourPitchforks]

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.

[vcsjones]

@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.