Switch Apple's digest functionality to CryptoKit

[vcsjones]

This changes our implementation of hashing to be based on CryptoKit instead of CommonCrypto. This will set us up on a path for success to eventually add handling for SHA-3.

A couple of notes on implementation:

1. HMAC will be a follow up.
2. The goal of this was to make the Swift function interface be a drop in replacement for the C one, calling convention aside. Any changes to the p/invoke shape can / should be a follow up.
3. This will drop support for iOS / tvOS 12. Per discussion on Consider bumping minimum iOS / tvOS version to 13 #120457, this is "fine" but we should not merge this until it's been explicitly agreed upon that we are actually okay taking a change that will not work on iOS 12.2.

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

[vcsjones]

@akoeplinger added you as a reviewer largely for awareness and to better understand if we are ready to take a "break iOS 12" change for NET 11 or if we should sit on this longer.

[vcsjones]

After thinking about this more, I don't think the copy semantics work the way I an expecting them to.

finalize on CryptoKit hash functions is not mutating, so it seems to work more like a getCurrentHash. But the documentation clearly says "do not do that" and it's also not clear to me if copy of the swift struct is intended to be a different or not.

I think for SHA-2 we should stick with CommonCrypto to make clone and current work.

For SHA-3 we can implement with CryptoKit, but we will probably need to omit GetCurrentDigest and Clone. At least until CryptoKit has a clear way to "fork" a hash in a documented way.

[vcsjones]

Okay, after doing some more digging and testing - using a let binding on the hash state does duplicate the state the way we intend.

[Copilot]

Pull Request Overview

This PR migrates Apple platform's digest/hashing implementation from CommonCrypto to CryptoKit, positioning the codebase for future SHA-3 support while dropping support for iOS/tvOS 12.

Key Changes:

• Replaces C-based CommonCrypto digest implementation with Swift-based CryptoKit implementation
• Updates P/Invoke signatures to use Swift calling conventions
• Implements digest operations (one-shot, create, update, final, reset, clone, current) using CryptoKit's HashFunction protocol

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
pal_swiftbindings.swift	Adds HashBox wrapper class and implements all digest functions using CryptoKit hash types (MD5, SHA1, SHA256, SHA384, SHA512)
pal_swiftbindings.h	Adds extern C declarations for the new Swift-implemented digest functions
pal_digest.h	Removes function declarations that are now implemented in Swift
pal_digest.c	Removes entire C implementation of digest functions based on CommonCrypto
CMakeLists.txt	Removes pal_digest.c from build sources
Interop.Digest.cs	Adds Swift calling convention attributes to P/Invoke declarations

[bartonjs]

Assuming we're good with the min-ver bump, LGTM.

Invalid review.

[vcsjones]

@akoeplinger are there any other pipelines we should run for confidence in mobile Apple platforms? I am not sure what is included in the "smoke" ones.

[akoeplinger]

I am not sure what is included in the "smoke" ones.

Easiest way is to check the Helix workitems, right now it's running mostly System.Runtime.Tests.

[akoeplinger]

/azp run runtime-ioslikesimulator

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[akoeplinger]

runtime-ioslikesimulator is green, merging :)