Catch-up merge main into wwdc25 branch #403

Lukasa · 2025-08-29T08:25:14Z

No description provided.

Fixed the documentation comment for the constructors * `init(unsafePEMRepresentation:)` * `init(unsafeDERRepresentation:)` of **`_RSA.Signing.PrivateKey`** which said "*public* key" instead of "*private* key". ### Modifications: No code changes.

@unchecked

…#366) Motivation Both of these types should be CoW data structures that are inherently Sendable. This will make programming with them substantially easier. Modifications - ArbitraryPrecisionInteger gets marked @unchecked Sendable - Refactor EllipticCurvePoint to become a CoW value type - Make EllipticCurvePoint @unchecked Sendable Results Easier to use types

Add static SDK CI workflow which runs on commits to PRs, merges to main and daily on main. --------- Co-authored-by: Cory Benfield <[email protected]>

This PR enables Windows CI on `main`, as well as on PRs.

### Motivation PKCS#8 is pretty widely used. Currently getting a key in PKCS#8 DER representations requires going through a PKCS8 PEM document and then get its DER bytes. ### Modifications Add a computed property to RSA private keys that calls into BoringSSL or Security.framework to get the PKCS8 DER representation of the key. ECDH keys use the existing `derRepresentation` property to provide a property of the same name. A small ASN1 encoder adds the functionality to ed25519/x25519 keys. ### Result The representation can be accessed directly. *The identifiers for MLKEM are [still a draft](https://datatracker.ietf.org/doc/draft-ietf-lamps-kyber-certificates/). As such MLKEM is not included in the PR.* --------- Co-authored-by: Cory Benfield <[email protected]>

### Motivation: Depending on the platform Swift Crypto Extras might use an implementation backed by `Security.framework`, specifically for RSA. Since BoringSSL is a necessary dependency on all platforms, we can deduplicate the implementation and keep a single backend. ### Modifications: Remove the `Security.framework` implementation and tie the RSA backend to BoringSSL. ### Result: Swift Crypto Extras always uses the BoringSSL backend for RSA. --------- Co-authored-by: Cory Benfield <[email protected]>

## Motivation The ARC IETF draft has been updated to now support P256 and drop support for P384. ## Modifications - Update the internal ARC implementation to accommodate multiple curves - Add API surface for P256 - Deprecate API for P384 - Add tests for P256 with test vectors from the draft - Move over the end-to-end API tests to P256 - Add benchmarks for P256 ## Result - New API `P256._ARCV1`, which provides an implementation of ARC(P-256). - Deprecate `P384._ARCV1`, which provides an implementation of ARC(P-256). [^1]: https://chris-wood.github.io/draft-arc/draft-yun-cfrg-arc.html#name-arcv1-p256 --------- Co-authored-by: Cory Benfield <[email protected]>

SwiftCrypto depends on SwiftASN1 which is declared in the exports file, but does not try to find the project, resulting in build failures of downstream projects that fail to explicitly call `find_package(SwiftASN1)` before `find_package(SwiftCrypto)`. Generally, it is recommended that project config files use `find_dependency` to search for the dependencies of the project they represent (https://cmake.org/cmake/help/v3.26/module/CMakeFindDependencyMacro.html). If the package is already found, either through `find_package` in the parent project, or through another means, the `find_dependency` call is a no-op. Co-authored-by: Cory Benfield <[email protected]>

Provides a typealias for `CryptoKitError` to hide the implementation detail of CryptoKit. Resolves apple#274 ### Motivation: CryptoKit is an implementation detail on Apple platforms - this makes it clearer for users coming from other platforms ### Modifications: Added a type alias and updated documentation Co-authored-by: Cory Benfield <[email protected]>

This addresses apple#369 (comment) We have passing Windows CI on PRs, so we should update our README to include ARM64 Windows as a supported platform.

Make swift-crypto build on Windows ### Checklist - [X] I've run tests to see all new and existing tests pass - [X] I've followed the code style of the rest of the project - [X] I've read the [Contribution Guidelines](CONTRIBUTING.md) - [X] I've updated the documentation if necessary #### If you've made changes to `gyb` files - [N/A] I've run `.script/generate_boilerplate_files_with_gyb` and included updated generated files in a commit of this pull request ### Motivation: Currently, swift-crypto on the main branch does not build on Windows. ### Modifications: * Add the Windows Arm64 assembly files to the CMake build. * Add appropriate CMake options for swift-crypto to build on Windows. ### Result: swift-crypto can be built on Windows from main Fixes apple#369 --------- Co-authored-by: Cory Benfield <[email protected]>

This patch works around the absence of a fix for swiftlang/swift#76186 on older Swift compilers.

Motivation: Version 3.13.0 hits a compiler assertion when compiling in release mode on Linux with Swift 6.1. This appears to stem from missing inlinable annotations. Modifications: - Add a few more `@inlinable` and `@usableFromInline` annotations Result: Builds on 6.1+ in release mode

We should have some benchmarks for EC key agreement.

Motivation We shouldn't repeatedly reconstruct static data Modifications - Turn the groups into static lets instead of computed properties Result Fewer allocations

Enable release mode build tests in CI ### Motivation: Some errors do not show up in debug builds. Enabling release mode builds improves the CI coverage. ### Modifications: Add a new workflow for release mode builds and enable it in the pull requests workflow. ### Result: The CI performs release mode builds to test pull requests. --------- Co-authored-by: George Barnett <[email protected]>

Add Sequence conformance to `AES._CBC.IV` where `Element` is `UInt8`.  ### Checklist - [ ] I've run tests to see all new and existing tests pass > PKCS8DERRepresentationTests do not compile on master branch with Error `'pkcs8DERRepresentation' is only available in iOS 14.0 or newer`. All the other tests pass after my changes. - [x] I've followed the code style of the rest of the project - [x] I've read the [Contribution Guidelines](CONTRIBUTING.md) - [x] I've updated the documentation if necessary #### If you've made changes to `gyb` files - [ ] I've run `.script/generate_boilerplate_files_with_gyb` and included updated generated files in a commit of this pull request ### Motivation: No convenient API for converting `AES._CBC.IV` into `Data`. ### Modifications: Added `Sequence` conformance to `AES._CBC.IV` similarly how it is done for `AES.GCM._SIV.Nonce`. ### Result: It will be possible to create `Data` instance with `AES._CBC.IV` passed as init argument. --------- Co-authored-by: Cory Benfield <[email protected]>

Motivation AES CMAC is a standardised albeit somewhat uncommon MAC built on top of the AES block cipher. CMAC pops up in a few places, mostly where it is convenient to assume that you have access to AES, but not to a hash function. For example, AES-SIV is built on CMAC. Modifications Add CMAC support Add tests and test vectors Result CMAC is supported

…ple#395) ## Motivation We were using a `@TaskLocal static var` to hold the `FiniteFieldArithmeticContext` (FFAC) on each of the curve types. The intention here was this would operate as a thread-local value, since task-locals behave like thread locals when the caller is not part of a task context. However, they still require binding, (i.e. the use of e.g. `P256.$__ffac.withValue { ... }`[^1], otherwise they just return the _default_ value, which is globally shared. We were not doing that, nor do we have a sensible place where we could. This causes crashes when using these values in a multithreaded environment since the same value will be used across threads. ## Modifications - Use an explicit thread-local API from Foundation to store and read the per-curve FFAC. - Add a test that shows each thread gets the same value on each read, but distinct from all other threads. ## Result Fixes crash when using ECToolbox-based APIs in multithreaded code. [^1]: https://developer.apple.com/documentation/swift/tasklocal#Using-task-local-values-outside-of-tasks

@Lukasa

Updates for the `scripts/vendor-boringssl.h` script that make it a bit easier to use and ensure you don't accidentally get an update of BoringSSL you don't want. ### Motivation: I was working on investigating building a Swift SDK for apple#223 and ran into a couple of things that I saw could be improved. Not all need to be done, but at the very least I feel the boringssl revision lock should be considered. @Lukasa ### Modifications: - Add missing invocation of `$sed` in the script- `gsed` was being invoked instead, although everywhere else `$sed` was used (typo). - Support locking `BORINGSSL_REVISION` to a specific revision number through an argument to the script. This way the script can be re-run without unintentionally upgrading boringssl. - Remove the non-existent `boringssl_prefix_symbols_nasm.inc` exclude from the `CCryptoBoringSSL` target. I'm guessing it was there for an older version of boringssl, but no longer there with the current revision? ### Result: The `scripts/vendor_boringssl.sh` script behaves a bit better and can be run without upgrading the boringssl version unless explicitly desired.

@Lukasa

… swift-sdk-generator) (apple#399) Swift SDK solution for adding armv7 symbols for swift-crypto using the [swift-sdk-generator](https://github.com/swiftlang/swift-sdk-generator). ### Motivation: As outlined in apple#223, the necessary symbols for armv7 are missing from swift-crypto, and we'd like to add them in some way that could be accepted by the team. It was discussed that using Swift SDKs generated from the swift-sdk-generator could be a solution that could be easily vetted, since the swift-sdk-generator is a component maintained by Apple and the swiftlang organization. ### Modifications: - Added a new `./scripts/generate-linux-sdks.sh` script to clone & build the swift-sdk-generator, and create Swift SDKs for x86_64, aarch64, and armv7. - Modified the `./scripts/vendor-boringssl.sh` script to use these installed Swift SDKs to cross-compile for Linux architectures in the script. - Ran the scripts against the exact revision of BoringSSL to avoid source updates, which adds the missing symbols for armv7. ### Result: Swift SDKs are used to generate symbols for Linux architectures instead of Docker, and missing symbols for armv7 are added as well. I have a few pros and cons for this solution: - Pros - Swift SDKs are used to cross-compile for Linux instead of Docker, which performs better than Rosetta 2 emulation. Docker does not have to be used at all for this solution. - Switching to using Swift SDKs is the more "correct" way to cross-compile for Linux targets, and much of the ecosystem for cross-compilation of Swift packages is moving to using Swift SDKs. - Cons - Lots of downloads need to happen since the swift-sdk-generator needs to download the host macOS toolchain for Swift 5.10, plus Ubuntu packages and target toolchains for each architecture (x86_64, aarch64, armv7). This results in ~15GB of artifacts in the /tmp directory for just the generator artifacts. However, this only needs to be run once before running the vendoring script. Let me know what you think @Lukasa.

### Motivation: swift-crypto currently fails to compile with TSAN enabled in 5.10 and 6.0 due to a TSAN error stemming from the use of `consuming` in the `finalize()` method of `_CryptoExtras/AES/CMAC`. ### Modifications: Like apple#384, the `consuming finalize()` method in `_CryptoExtras/AES/CMAC` is now wrapped inside a `#if compiler(>=6.1)` condition. A non-consuming variant is used otherwise. ### Result: `swift-crypto` can successfully compile with TSAN enabled in 5.10 and 6.0.

Merge remote-tracking branch 'origin/main' into cb-catchup-merge-20250829

Motivation In preparation for adopting FoundationEssentials where available, we need to avoid using Thread as that isn't available. To that end, let's bring over NIO's ThreadSpecificVariable wrapper. Modifications Bring over NIO's ThreadSpecificVariable wrapper and supporting code. Result No need for Thread anymore.

…0829

Fix PR template to point to correct script

This little box type allows us to easily audit the correctness of the locking.

…0829

simonjbeaumont

Looks good. Not sure I've understood the introduction of the CryptoError type alias and whether there's more rollout of that still to come.

simonjbeaumont · 2025-09-09T12:54:07Z

README.md

@@ -129,7 +129,7 @@ What this means for you is that you should depend on Swift Crypto with a version
 In SwiftPM that can be easily done specifying for example `from: "1.0.0"` meaning that you support Swift Crypto in every version starting from 1.0.0 up to (excluding) 2.0.0.
 SemVer and Swift Crypto's Public API guarantees should result in a working program without having to worry about testing every single version for compatibility.

-Swift Crypto 2.0.0 was released in September 2021. The only breaking change between Swift Crypto 2.0.0 and 1.0.0 was the addition of new cases in the `CryptoKitError` enumeration. For most users, then, it's safe to depend on either the 1.0.0 _or_ 2.0.0 series of releases.
+Swift Crypto 2.0.0 was released in September 2021. The only breaking change between Swift Crypto 2.0.0 and 1.0.0 was the addition of new cases in the `CryptoError` enumeration. For most users, then, it's safe to depend on either the 1.0.0 _or_ 2.0.0 series of releases.


Think some find-replace went a little off here.

Suggested change

Swift Crypto 2.0.0 was released in September 2021. The only breaking change between Swift Crypto 2.0.0 and 1.0.0 was the addition of new cases in the `CryptoError` enumeration. For most users, then, it's safe to depend on either the 1.0.0 _or_ 2.0.0 series of releases.

Swift Crypto 2.0.0 was released in September 2021. The only breaking change between Swift Crypto 2.0.0 and 1.0.0 was the addition of new cases in the `CryptoKitError` enumeration. For most users, then, it's safe to depend on either the 1.0.0 _or_ 2.0.0 series of releases.

simonjbeaumont · 2025-09-09T13:02:51Z

Sources/_CryptoExtras/RSA/RSA+BlindSigning.swift

@@ -499,7 +499,7 @@ extension _RSA.BlindSigning.PublicKey {
 extension _RSA.BlindSigning {
    /// Errors defined in the RSA Blind Signatures protocol.
    ///
-    /// - NOTE: This type does not conform to `Swift.Error`, it is used to construct a `CryptoKitError`.
+    /// - NOTE: This type does not conform to `Swift.Error`, it is used to construct a `CryptoError`.


Suggested change

/// - NOTE: This type does not conform to `Swift.Error`, it is used to construct a `CryptoError`.

/// - NOTE: This type does not conform to `Swift.Error`, it is used to construct a `CryptoKitError`.

simonjbeaumont · 2025-09-09T13:03:03Z

Sources/_CryptoExtras/RSA/RSA+BlindSigning.swift

@@ -516,7 +516,7 @@ extension _RSA.BlindSigning {

 @available(macOS 10.15, iOS 13, watchOS 6, tvOS 13, macCatalyst 13, visionOS 1.0, *)
 extension CryptoKitError {
-    /// Map an error from the RSA Blind Signatures protocol to a CryptoKitError.
+    /// Map an error from the RSA Blind Signatures protocol to a CryptoError.


Suggested change

/// Map an error from the RSA Blind Signatures protocol to a CryptoError.

/// Map an error from the RSA Blind Signatures protocol to a CryptoKitError.

Lukasa · 2025-09-09T15:12:27Z

Those changes were intentional and part of #285.

YourMJK and others added 24 commits June 16, 2025 07:44

Add static SDK CI workflow (apple#340)

6214426

Add static SDK CI workflow which runs on commits to PRs, merges to main and daily on main. --------- Co-authored-by: Cory Benfield <[email protected]>

Enable Windows CI on main (apple#371)

7416764

This PR enables Windows CI on `main`, as well as on PRs.

Mention Windows in README (apple#378)

e5f10a7

This addresses apple#369 (comment) We have passing Windows CI on PRs, so we should update our README to include ARM64 Windows as a supported platform.

Back out changes post-quantum changes for release (apple#379)

75475b8

Work around Swift compiler issue with consuming and TSAN (apple#384)

88b9c9b

This patch works around the absence of a fix for swiftlang/swift#76186 on older Swift compilers.

Add some benchmarks for EC key agreement (apple#390)

64a4de0

We should have some benchmarks for EC key agreement.

Cache curves to avoid repeatedly reallocating state (apple#391)

176abc2

Motivation We shouldn't repeatedly reconstruct static data Modifications - Turn the groups into static lets instead of computed properties Result Fewer allocations

Catch-up merge main into wwdc25 branch

143c896

Merge remote-tracking branch 'origin/main' into cb-catchup-merge-20250829

Lukasa added the semver/none No version bump required. label Aug 29, 2025

Lukasa and others added 5 commits August 29, 2025 12:41

Fix merge error

2b7be8b

Merge remote-tracking branch 'origin/main' into cb-catchup-merge-2025…

0e02512

…0829

Re-add accidentally deleted files

a519b5d

Fix script path in PR template (apple#408)

9552067

Fix PR template to point to correct script

Lukasa mentioned this pull request Sep 9, 2025

Rename _CryptoExtras Take 2 #407

Open

5 tasks

Lukasa added 5 commits September 9, 2025 09:04

Make the tests Swift 6 ready. (apple#409)

141f5b4

This little box type allows us to easily audit the correctness of the locking.

Merge remote-tracking branch 'origin/main' into cb-catchup-merge-2025…

2e6518c

…0829

Speculative fix to get Sendable warnings solved in Xcode 16.2

0717f67

Appease the formatter

6e36370

Formatter finally appeased

0bb59c8

simonjbeaumont approved these changes Sep 9, 2025

View reviewed changes

Lukasa merged commit 890595d into apple:wwdc-25 Sep 9, 2025
40 of 44 checks passed

Lukasa deleted the cb-catchup-merge-20250829 branch September 9, 2025 15:12

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Catch-up merge main into wwdc25 branch #403

Catch-up merge main into wwdc25 branch #403

Uh oh!

Lukasa commented Aug 29, 2025

Uh oh!

simonjbeaumont left a comment

Uh oh!

simonjbeaumont Sep 9, 2025

Uh oh!

simonjbeaumont Sep 9, 2025

Uh oh!

simonjbeaumont Sep 9, 2025

Uh oh!

Lukasa commented Sep 9, 2025

Uh oh!

Uh oh!

Uh oh!

	Swift Crypto 2.0.0 was released in September 2021. The only breaking change between Swift Crypto 2.0.0 and 1.0.0 was the addition of new cases in the `CryptoError` enumeration. For most users, then, it's safe to depend on either the 1.0.0 _or_ 2.0.0 series of releases.
	Swift Crypto 2.0.0 was released in September 2021. The only breaking change between Swift Crypto 2.0.0 and 1.0.0 was the addition of new cases in the `CryptoKitError` enumeration. For most users, then, it's safe to depend on either the 1.0.0 _or_ 2.0.0 series of releases.

	/// - NOTE: This type does not conform to `Swift.Error`, it is used to construct a `CryptoError`.
	/// - NOTE: This type does not conform to `Swift.Error`, it is used to construct a `CryptoKitError`.

	/// Map an error from the RSA Blind Signatures protocol to a CryptoError.
	/// Map an error from the RSA Blind Signatures protocol to a CryptoKitError.

Catch-up merge main into wwdc25 branch #403

Catch-up merge main into wwdc25 branch #403

Uh oh!

Conversation

Lukasa commented Aug 29, 2025

Uh oh!

simonjbeaumont left a comment

Choose a reason for hiding this comment

Uh oh!

simonjbeaumont Sep 9, 2025

Choose a reason for hiding this comment

Uh oh!

simonjbeaumont Sep 9, 2025

Choose a reason for hiding this comment

Uh oh!

simonjbeaumont Sep 9, 2025

Choose a reason for hiding this comment

Uh oh!

Lukasa commented Sep 9, 2025

Uh oh!

Uh oh!

Uh oh!