Add "external mu" variant of ML-DSA (65 and 87) in _CryptoExtras
#358
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This PR sets swift-crypto up for alignment with the WWDC 2025 CryptoKit APIs. This includes the parity APIs for MLKEM and MLDSA, as well as XWing. At this time the SHA3 APIs are disabled, as they require a novel implementation strategy. This will come later in the summer. All API features that require SHA3 are therefore also disabled at runtime.
…nts)" This reverts commit e9de693.
…nts)" This reverts commit e9de693.
…ft-crypto into mldsa-external-mu
fpseverino
changed the title
_CryptoExtras
### Motivation: FoundationEssentials produces smaller binaries on most platforms. ### Modifications: Where FoundationEssentials is available, import that. ### Result: Improved binary size
To keep the WWDC-25 branch from rotting too badly, we'll be doing regular catch-up merges. This is the first. Co-authored-by: YourMJK <[email protected]>
fpseverino
commented
Jun 18, 2025
Comment on lines
-28
to
-34
|
|
||
| @_implementationOnly import CCryptoBoringSSL | ||
| #if canImport(FoundationEssentials) | ||
| import FoundationEssentials | ||
| #else | ||
| import Foundation | ||
| #endif |
There was a problem hiding this comment.
These imports were duplicated in the same file
Comment on lines
35
to
36
| public func signature(forPrehashedMessageRepresentative mu: some DataProtocol) throws -> Data { | ||
| try self.signature_boring(forPrehashedMessageRepresentative: mu) |
There was a problem hiding this comment.
The public method here and the equivalent package one defined in Crypto/Signatures/MLDSA.swift must have different names, otherwise the compiler thinks we are calling the same method and throws the warning Function call causes an infinite recursion.
|
|
||
| private var boringSSLKey: OpenSSLMLDSAPublicKeyImpl<MLDSA65> { | ||
| get throws { | ||
| self.impl is OpenSSLMLDSAPublicKeyImpl<MLDSA65> |
There was a problem hiding this comment.
This throws the warning 'is' test is always true, should we use #if checks instead?
There was a problem hiding this comment.
I've updated it to use #if checks
Co-authored-by: YourMJK <[email protected]>
Motivation The Swift 6 language mode adopts data-race safety by default. While Swift Crypto itself has no concurrent code, it is still useful to force us to ensure that our code is properly Sendable-correct. Modifications - @unchecked Sendable on several CoW data types - Some necessary Sendable constraints on ECToolbox protocols - Add some missing protocol constraints on ARC types. Result Swift 6 clean.
This patch brings us up-to-date with the RC SDK. There are a couple of tweaks to the MLDSA code and the XWing code, mostly a few minor interface changes. I've adopted those in the backing code, and also wired up the SHA3 integrity checks.
Lukasa
reviewed
Sep 12, 2025
| self.impl | ||
| #endif | ||
| } | ||
| } |
There was a problem hiding this comment.
Can these pieces be moved into another file in this project and declared as extension methods? Ideally they'd stay out of the shared code, and in a BoringSSL directory instead.
Following on from apple#281, opened as a new PR as the conflicts were too many ### 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 - [ ] I've run `.script/generate_boilerplate_files_with_gyb` and included updated generated files in a commit of this pull request ### Motivation: _[Explain here the context, and why you're making that change. What is the problem you're trying to solve.]_ ### Modifications: _[Describe the modifications you've done.]_ ### Result: _[After your change, what will change.]_
Merge CryptoExtras rename
This convinience method will be used by SLHDSA, which will be located in `CryptoExtras`, and could also be used by `MLDSA44`, also to be located in `CryptoExtras`
fpseverino
commented
Sep 15, 2025
| @@ -19,7 +19,9 @@ import Foundation | |||
| #endif | |||
|
|
|||
| extension Optional where Wrapped: DataProtocol { | |||
| func withUnsafeBytes<ReturnValue>(_ body: (UnsafeRawBufferPointer) throws -> ReturnValue) rethrows -> ReturnValue { | |||
| package func withUnsafeBytes<ReturnValue>( | |||
There was a problem hiding this comment.
This convinience method will be used by SLHDSA, which will be located in CryptoExtras, and could also be used in the future by MLDSA44, which will also need to be located in CryptoExtras.
This is the last catchup merge into the WWDC-25 branch required to get the two branches to line up. From here, it's a straightforward merge to `main` to get the WWDC-25 branch in. --------- Co-authored-by: YourMJK <[email protected]> Co-authored-by: Rick Newton-Rogers <[email protected]> Co-authored-by: Raphael <[email protected]> Co-authored-by: Si Beaumont <[email protected]> Co-authored-by: Evan Wilde <[email protected]> Co-authored-by: Tim Condon <[email protected]> Co-authored-by: Gus Cairo <[email protected]> Co-authored-by: George Barnett <[email protected]> Co-authored-by: Fabrice de Gans <[email protected]> Co-authored-by: Wojciech Nagrodzki <[email protected]> Co-authored-by: Jesse L. Zamora <[email protected]> Co-authored-by: aryan-25 <[email protected]> Co-authored-by: Gwynne Raskind <[email protected]> Co-authored-by: 3405691582 <[email protected]> Co-authored-by: Paul Toffoloni <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Add an "external mu" variant of the ML-DSA API (65 and 87 variants) in
_CryptoExtras.Checklist
If you've made changes to
gybfiles.script/generate_boilerplate_files_with_gyband included updated generated files in a commit of this pull requestMotivation:
BoringSSL now has an “external mu” variant of the ML-DSA API, which makes it possible to calculate the hash (called “mu”) of the message, context and public key separately, and then pass this “mu” to a signing function.
Basically, it is the same process as the traditional signature function, but separated into two steps.
This is supposed to be the alternative to the HashML-DSA algorithm, which does pure pre-hashing.
Modifications:
Add the "external mu" API to
MLDSA65andMLDSA87when importing_CryptoExtras, add tests.Result:
The "external mu" variant of ML-DSA is now available in
_CryptoExtras.