Wire ML-DSA into the crypto backend#2342
Conversation
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!
|
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. |
| + // Bytes returns only the 32-byte seed, which is the same length for all | ||
| + // parameter sets, so the parameter sets must be compared separately to | ||
| + // match the standard library Equal, which distinguishes them. | ||
| + return sk.paramSet() == other.paramSet() && |
There was a problem hiding this comment.
Hmm, think should Go into the backends. As a general rule (which has exceptions), we shouldn't implement in this layer operations that upstream implements in internal/fips140. For example, OpenSSL support EVP_PKEY_eq. I'm not sure ifCNG/CryptoKit provide similar helpers. If they don't, then we can always fallback to comparing the bytes in the backend.
There was a problem hiding this comment.
In theory this block implements compatibility between boring sk and Go other and vice versa, it sounds like there should be a new initial "both boring" case that calls into the backend to implement this (if supported) rather than using subtle.ConstantTimeCompare?
michelle-clayton-work
force-pushed
the
dev/mclayton/mldsa-backend
branch
2 times, most recently
from
465bf73 to
756f2ef
Compare
michelle-clayton-work
force-pushed
the
dev/mclayton/mldsa-backend
branch
from
756f2ef to
3d900a3
Compare
| Title: "ML-DSA", | ||
| ColumnHeader: "Parameters", | ||
| Packages: []string{"crypto/mldsa"}, | ||
| MinGoVersion: "1.26", |
There was a problem hiding this comment.
Is it true that we're planning to backport this from 1.27?
(If so, we should hold off on the doc change until we actually do.)
There was a problem hiding this comment.
I don't think it's possible to backport this as it only landed in gotip. Let's update this to be 1.27
There was a problem hiding this comment.
| MinGoVersion: "1.26", | |
| MinGoVersion: "1.27", |
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.