Repository navigation
Add ML-DSA signing and verification support - #54018
adilalperenciftci wants to merge 1 commit into
Conversation
3cc01b3 to
c6c5a8f
Compare
|
DCO passes on the current head, but the GitHub Actions workflows still need maintainer approval and there is no human review yet. Could a maintainer approve the workflows and take a first look? |
Closes keycloak#52816 Signed-off-by: Adil Alperen Ciftci <adilalperenciftci@users.noreply.github.com>
c6c5a8f to
53f8dac
Compare
|
Rebased onto current main (d4d5554) in 53f8dac. The client-attestation conflict now retains upstream's x5c certificate-chain argument and the canonical algorithm handling. The remaining adjustments are import-only formatting fixes in the existing PR files. Validated in the Ubuntu lab with JDK 21:
FIPS and server integration environments were not tested. Could a maintainer approve the updated workflows and review the ML-DSA support? |
There was a problem hiding this comment.
🟡 Changes recommended
Premature capability checks exclude all ML-DSA factories from clean Quarkus builds, while algorithm-name mismatches break integration paths and the truncated-signature test fails on JDK 25.
5 open issues
Augmentation filters ML-DSA factories before crypto provider initialization · New Truncated-signature test fails when verifier throws VerificationException · New UserInfo lookup uses enum name instead of ML-DSA JOSE value · New JWS header validation rejects ML-DSA algorithm values · New CIBA signing algorithm parsing rejects advertised ML-DSA values · New
Review effort: Max
| if (!ALGORITHMS.contains(algorithm) || !CryptoIntegration.isInitialised()) { | ||
| return false; |
| MLDSASignatureProvider provider = new MLDSASignatureProvider(session, Algorithm.ML_DSA_44); | ||
| byte[] signature = provider.signer(key).sign(PAYLOAD); | ||
|
|
||
| assertFalse(provider.verifier(key).verify(PAYLOAD, Arrays.copyOf(signature, signature.length - 1))); |
| ML_DSA_44(AlgorithmType.ML_DSA, null, org.keycloak.crypto.Algorithm.ML_DSA_44), | ||
| ML_DSA_65(AlgorithmType.ML_DSA, null, org.keycloak.crypto.Algorithm.ML_DSA_65), | ||
| ML_DSA_87(AlgorithmType.ML_DSA, null, org.keycloak.crypto.Algorithm.ML_DSA_87) |
| throw new VCIssuerException(ErrorType.INVALID_PROOF, "Key with kid '" + header.getKeyId() + "' not found in trusted key registry"); | ||
| } | ||
| verifier = verifierFromResolvedJWK(resolvedJwk, header.getAlgorithm().name(), keycloakSession); | ||
| verifier = verifierFromResolvedJWK(resolvedJwk, header.getRawAlgorithm(), keycloakSession); |
| org.keycloak.crypto.MLDSA44SignatureProviderFactory | ||
| org.keycloak.crypto.MLDSA65SignatureProviderFactory | ||
| org.keycloak.crypto.MLDSA87SignatureProviderFactory |
|
Thanks for the PR, but I'm going to close this as it is trying to add too many things in one go, completely lacking on functional tests, and does not work at all beyond in unit tests. The way the providers are enabled/disabled basically means they will never be available in the server. |


Summary
The factories are unavailable when the active crypto provider does not expose the required ML-DSA services, including BC-FIPS configurations without ML-DSA support.
Testing
./mvnw -pl core -Dtest=MLDSAAlgorithmTest test./mvnw -pl crypto/default -Dtest=DefaultCryptoAKPJWKTest test./mvnw -pl services "-Dtest=CryptoUtilsTest,MLDSASignatureProviderTest,MLDSAClientSignatureVerifierProviderTest,GeneratedMLDSAKeyProviderTest,JWKSServerUtilsTest" test./mvnw -pl server-spi-private testFixes #52816
Addresses #52815