Description of the issue
I have a set of CodeQL queries for Java that detect misuse of post-quantum APIs, and I would like to check whether they are wanted here, and in what shape, before opening a PR.
The existing experimental/quantum work answers "which cryptography is quantum-vulnerable and where is it": the CBOM graph, the InventorySlices queries, and the QuantumVulnerable* demo queries in #21354. The gap I am proposing to fill is the other direction: code that has already adopted ML-KEM or ML-DSA and wires it up incorrectly. Those are ordinary implementation bugs, but they are invisible to inventory queries because the algorithm inventory looks correct.
Eight patterns, all targeting the KEM and PQC signature APIs:
| ID |
Pattern |
| KEM-01 |
KEM ciphertext used as key material |
| KEM-02 |
Raw ML-KEM shared secret used as a symmetric key with no KDF |
| KEM-03 |
Shared secret truncated |
| KEM-04 |
Static or reused KEM keypair, losing forward secrecy |
| HYB-01 |
Hybrid key exchange silently downgrading to the classical component |
| SIG-01 |
Signature verification result ignored |
| SIG-02 |
Predictable RNG for key generation |
| API-01 |
Deprecated pre-standardization Kyber/Dilithium APIs instead of FIPS 203/204 |
Does it find real bugs? On gematik/lib-vau@a583b04, currently the head of main, which is the reference implementation of the VAU protocol for Germany's national electronic patient record, API-01 reports three true positives: KyberParameterSpec.kyber768 in KyberEncoding.java:58 and KeyFactory.getInstance("KYBER", "BCPQC") in VauBasicPublicKey.java:80. Both are BouncyCastle's round-3 API rather than FIPS 203 ML-KEM. Their round-3 pin appears deliberate for spec compliance, so this is a migration-liability finding rather than an exploitable bug, but the detection itself is accurate.
As a check in the other direction, all eight queries report nothing on i2p/i2p.i2p@e52a015, which uses ML-KEM correctly by feeding the shared secret into a Noise HKDF chain. That zero is not an extraction artifact: a probe query confirms the database resolved MLKEMExtractor.extractSecret, MLKEMGenerator.generateEncapsulated and SecretWithEncapsulation.getSecret. The KEM-02 detector uses value-preserving local flow, so a KDF on the path stops the flow and correct code is spared without needing an allowlist of KDF APIs.
Beyond that I only have a self-built labelled corpus (24 sites), which I would not present as generalization evidence.
What I would like to know before doing the work:
- Are misuse queries of this kind wanted in
java/ql/src/experimental/quantum, or is that directory intended to stay inventory and classification only?
- Should they be built on the crypto model rather than plain AST plus dataflow? As far as I can tell the model does not yet reach the APIs these queries target.
JCA.qll recognises ML-KEM by name but maps it to Crypto::OtherKeyAgreementType(), javax.crypto.KEM (JDK 21 and later) does not appear in JCA.qll at all, nor does BouncyCastle's low-level MLKEMGenerator/MLKEMExtractor pair, and KeyEncapsulationOperationNode in Model.qll is keyed to wrap and unwrap modes rather than encapsulate and decapsulate. TKeyEncapsulation(OtherKEMAlgorithmType()) appears only as a documented type hint. The library-tests/quantum/jca/KeyEncapsulation.java fixture looks like it was heading this way, since its Kyber section and the BouncyCastle PQC imports are commented out, and its own javadoc notes that "directly using the raw ECDH shared secret as key material is insecure in production", which is the classical sibling of KEM-02 in the table above. So the choice looks like either extending the model with KEM operation instances first and writing the queries on top, or writing them against the Java AST and dataflow for now and migrating later. I would rather follow your preference than guess.
- If this is welcome, would you prefer one query first (API-01 is the one with the real-world true positive) so the shape can be reviewed, rather than eight at once?
Happy to do the porting, @tags experimental, java/ query IDs, autoformatting, qhelp and tests. I would rather ask first than send eight queries written against the wrong layer. The queries and evidence are at https://github.com/Arpan0995/pqc-api-misuse-codeql (Apache-2.0).
Description of the issue
I have a set of CodeQL queries for Java that detect misuse of post-quantum APIs, and I would like to check whether they are wanted here, and in what shape, before opening a PR.
The existing
experimental/quantumwork answers "which cryptography is quantum-vulnerable and where is it": the CBOM graph, theInventorySlicesqueries, and theQuantumVulnerable*demo queries in #21354. The gap I am proposing to fill is the other direction: code that has already adopted ML-KEM or ML-DSA and wires it up incorrectly. Those are ordinary implementation bugs, but they are invisible to inventory queries because the algorithm inventory looks correct.Eight patterns, all targeting the KEM and PQC signature APIs:
Does it find real bugs? On
gematik/lib-vau@a583b04, currently the head ofmain, which is the reference implementation of the VAU protocol for Germany's national electronic patient record, API-01 reports three true positives:KyberParameterSpec.kyber768inKyberEncoding.java:58andKeyFactory.getInstance("KYBER", "BCPQC")inVauBasicPublicKey.java:80. Both are BouncyCastle's round-3 API rather than FIPS 203 ML-KEM. Their round-3 pin appears deliberate for spec compliance, so this is a migration-liability finding rather than an exploitable bug, but the detection itself is accurate.As a check in the other direction, all eight queries report nothing on
i2p/i2p.i2p@e52a015, which uses ML-KEM correctly by feeding the shared secret into a Noise HKDF chain. That zero is not an extraction artifact: a probe query confirms the database resolvedMLKEMExtractor.extractSecret,MLKEMGenerator.generateEncapsulatedandSecretWithEncapsulation.getSecret. The KEM-02 detector uses value-preserving local flow, so a KDF on the path stops the flow and correct code is spared without needing an allowlist of KDF APIs.Beyond that I only have a self-built labelled corpus (24 sites), which I would not present as generalization evidence.
What I would like to know before doing the work:
java/ql/src/experimental/quantum, or is that directory intended to stay inventory and classification only?JCA.qllrecognises ML-KEM by name but maps it toCrypto::OtherKeyAgreementType(),javax.crypto.KEM(JDK 21 and later) does not appear inJCA.qllat all, nor does BouncyCastle's low-levelMLKEMGenerator/MLKEMExtractorpair, andKeyEncapsulationOperationNodeinModel.qllis keyed to wrap and unwrap modes rather than encapsulate and decapsulate.TKeyEncapsulation(OtherKEMAlgorithmType())appears only as a documented type hint. Thelibrary-tests/quantum/jca/KeyEncapsulation.javafixture looks like it was heading this way, since its Kyber section and the BouncyCastle PQC imports are commented out, and its own javadoc notes that "directly using the raw ECDH shared secret as key material is insecure in production", which is the classical sibling of KEM-02 in the table above. So the choice looks like either extending the model with KEM operation instances first and writing the queries on top, or writing them against the Java AST and dataflow for now and migrating later. I would rather follow your preference than guess.Happy to do the porting,
@tags experimental,java/query IDs, autoformatting, qhelp and tests. I would rather ask first than send eight queries written against the wrong layer. The queries and evidence are at https://github.com/Arpan0995/pqc-api-misuse-codeql (Apache-2.0).