Support SHA-3 on Apple CryptoKit

[vcsjones]

Apple CryptoKit on Apple Platforms 26+ will support SHA-3 and HMAC SHA-3. Right now this is blocked on the platform's availability and the build system having the right SDK available.

Currently, this looks like SHA-3 and HMAC SHA-3 only. No Shake or KMAC.

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[JohnGalt1717]

The argument that this can’t be done in time is the inverse of what happened last year where you couldn’t use .Net for an entire month on Mac because no one at Microsoft got the fix they knew they needed in on time to make sure that certs would actually keep working. (And then no one was willing to do an out of band sdk release with the fix in it)

But in this case, it would be trivial for actual testing with public betas just like Microsoft does with windows 11 on macOS and iOS and watchOS to get this working.

But no one will, and then Microsoft wonders why devs still harbor ill will to them and .net.

This is case in point stuff that harms reputation subtly. You’re adding functionality to .net 10 and it works everywhere but Mac and for absolutely no reason and completely unjustifiably.

Please rethink this and get this working. This isn’t like Android or even windows where users will take years to adopt. By the release of .net 10 over 80% of all Macs will be using a compatible version and virtually all of your developers will be.

[bartonjs]

There are a few points you've made, hopefully I address all of them.

that this can’t be done in time

Assuming I know the schedule, sometime tomorrow (Friday, Redmond time) dotnet/runtime:main becomes 11, and we start the process of battening down the hatches for 10-RTM. Technically speaking, we're just forking for RC1, but once that happens main is now vNext, and anything into 10 requires a very high bar. No one has started working on it yet, so it's unlikely that it will be written, tested, code reviewed, and merged by tomorrow. So getting into 10 is now "not easy" (not "impossible", but "not easy").

Before we can even start the work we need to move our macOS build process to using the macOS 26 SDK / XCode 26. Those upgrades rarely go super smoothly. We need the SDK so the new functions are available to call.

[implied] But it's easy, you already have SHA-2, and SHA-3 is just different strings.

No, SHA-2 is done from CommonCrypto/Security.framework, and SHA-3 needs to be done by CryptoKit. We've never had to manage CryptoKit object lifetime, so this isn't just "add a few strings", it's "do a completely new thing".

You’re adding functionality to .net 10

If you mean SHA-3, that's not new in 10. We added that in 8. We'd've added support on macOS at the time if Apple had made it available. And we'll add it once we can. That's just probably not for 10-RTM.

it would be trivial for actual testing with public betas just like Microsoft does with windows 11

The Windows functions have C exports. C exports from .NET are easy. We can "faith-call" them (don't need an SDK, just a promise they exist). CryptoKit is not as easy. We have to make a C-export shim to be able to call into it, and that means we need a library that compiles, and that means we need the SDK.

Please rethink this and get this working.

We'll get it working almost as soon as a) things we've already promised we're going to do are done, and b) it's technically feasible to do so in our build environment. I'm pretty confident on that because 1) @vcsjones is who opened this issue, 2) @vcsjones uses macOS, and 3) @vcsjones wrote the .NET SHA-3 support. That's a trifecta of @vcsjones motivation.

[JohnGalt1717]

Please review the excuse making for the ENTIRE MONTH that .NET didn't work on Mac last year around this very same time.

You've repeated the same mistakes again with the same excuses. You're implying that this wasn't known months ago. If you accept that premise, then sure, your argument is logical. But that isn't a factual statement, so everything that falls out of it is also void. The same technique to justify the failure last fall was used and was exposed as not factual based on the communication that was surfaced that Microsoft was aware in June of 2024 that they would have to update before the release of the new MacOS, yet chose to do nothing and didn't prioritize it and then deflected and ignored it for a month leaving developers high and dry.

I.e. 0 people on the .net team took it as a learning experience and adapted and fixed process so we're having yet another repeat, and we'll have it again next year because exactly the same sequence will occur then for exactly the same reasons because of .net failing to adjust process to Apple's release schedules. It will be a crap shoot of if that will be "you don't get the crypto that all new projects should be using" level bad, or "ya, your mac is a brick and you'll have to reinstall the entire operating system to an old version just to be able to develop again" bad.

I trust you see the institutional failure here.