Wire ML-DSA into the crypto backend#2342
Merged
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR extends the system crypto backend integration to ML-DSA, mirroring the existing ML-KEM wiring: when the crypto backend is enabled and supports the requested ML-DSA parameter set, crypto/mldsa routes keygen/parsing/sign/verify through the platform backend; otherwise it falls back to the Go FIPS 140-3 module.
Changes:
- Add ML-DSA shims to
crypto/internal/backendacross Linux (OpenSSL), Windows (CNG), and Darwin (CryptoKit), plusnobackendpanic stubs. - Update
crypto/mldsa/mldsa_fips140v1.26.goto carry backend handles in key types and dispatch supported operations to the backend (with fallback for unsupported operations like deterministic/external-mu signing). - Adjust
crypto/mldsatests to account for backend-backed key handles and backend-dependent allocation behavior.
Patches are happy!
Member
|
You'll need to update https://github.com/microsoft/go/blob/microsoft/main/eng/_util/cmd/updatecryptodocs/docs.go and run the generator to add ML-DSA to the crypto docs. |
qmuntal
requested changes
Jun 3, 2026
Closed
dagood
reviewed
Jun 3, 2026
756f2ef to
3d900a3
Compare
dagood
reviewed
Jun 3, 2026
Mechanical bump + 'go mod vendor' regen. No source changes in microsoft/go itself; the large diff is upstream maintenance accumulated since the previously-pinned versions (May 12), including the fakecgo 'DO NOT EDIT' header pass (go-crypto-darwin#209). Prerequisite for the crypto/mldsa Equal wiring follow-up PR.
c9201dc to
e1acb0d
Compare
Adds ML-DSA shims to backend_{linux,darwin,windows}.go and nobackend.go; updates crypto/mldsa std-lib to dispatch via the configured backend (boring.Equal, boring.Sign, boring.Verify) when available, falling back to the Go implementation otherwise. Also adds ML-DSA to the cross-platform crypto documentation.
Depends on #<bump-backends PR>.
de726a5 to
b348d6d
Compare
qmuntal
requested changes
Jun 8, 2026
| + if boring.Enabled && boring.SupportsMLDSA(boring.MLDSA65()) { | ||
| + switch runtime.GOOS { | ||
| + case "darwin", "windows": | ||
| + expected = 16 |
Member
There was a problem hiding this comment.
On my Windows machine, which supports ML-DSA, this tests only produces 8 allocations. 16 seems is too conservative.
The by-value boring.PrivateKeyMLDSA/PublicKeyMLDSA fields made mldsa.PrivateKey and mldsa.PublicKey too large to keep on the stack, regressing the Go-path allocation count and failing crypto/mldsa TestAllocations on CI (where no runner's system crypto implements ML-DSA, so the Go fallback always runs). Store the backend keys by pointer instead, which only grows the wrappers by one word, and update TestAllocations to expect the backend count when ML-DSA is backend-implemented and one extra allocation on the fallback path.
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
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.
Wires ML-DSA into the system crypto backend, mirroring the existing ML-KEM integration. When the backend is enabled and supports the requested parameter set,
crypto/mldsadispatches key generation, parsing, hedged signing, and verification to the native backend (OpenSSL / CNG / CryptoKit); otherwise it falls back to the Go FIPS 140-3 module.crypto/internal/backend: add ML-DSA shims forbackend_linux.go(OpenSSL),backend_windows.go(CNG),backend_darwin.go(CryptoKit), and panic stubs innobackend.go.crypto/mldsa/mldsa_fips140v1.26.go: add aboringbackend handle toPrivateKey/PublicKey, auseBoringMLDSAgate, and backend dispatch forGenerateKey,NewPrivateKey,newPublicKey,Bytes,PublicKey,Equal,Parameters, hedgedSign, andVerify.