Re: [PR] Add PQC (ML-DSA and ML-KEM) support for XML Dig ital Signature and Enc… [santuario-xml-security-java]

ffang commented on PR #645:
URL: https://github.com/apache/santuario-xml-security-java/pull/645#issuecomment-5318449428

   > I have been looking at post-quantum support across a number of Java crypto libraries and read through this PR with interest. Two choices in the KEM path stood out as the right ones: it takes the encapsulation length from the KEM API (Decapsulator.encapsulationSize()) rather than a hardcoded per-algorithm table, and it derives the key-wrap key through a KDF rather than using the raw shared secret.
   > 
   > One gap I noticed while reading the tests. The new PQC tests (XMLSignatureMLDSATest, XMLEncryptionMLKEMTest, StaxMLDSASignatureTest, StaxMLKEMEncryptionTest) all exercise the happy path only, sign-then-verify and encrypt-then-decrypt. For a signature and encryption feature it would be worth adding a few negative cases that lock in the security-relevant behaviour, for example:
   > 
   >     * a tampered ML-DSA signature (a flipped byte of SignatureValue) is rejected by verification;
   > 
   >     * an ML-DSA signature checked against the wrong public key fails;
   > 
   >     * ML-KEM decryption with the wrong recipient private key fails cleanly rather than returning wrong plaintext;
   > 
   >     * a truncated or corrupted KEM encapsulation (shorter than encapsulationSize, or a flipped byte) is rejected with a clear exception.
   > 
   > 
   > These are the cases that would catch a regression in the verify or decapsulate path later, and they are quick to add on top of the round-trip tests already there. Since you are planning to split this into separate Signature and Encryption PRs, the ML-DSA cases would go with the signature side and the ML-KEM cases with the encryption side. Happy to help with any of them if useful.
   
   Hi @Arpan0995 ,
   
   Thanks for the review, and glad the KEM length/KDF choices came through as intended.
   
   Good catch on the negative test coverage — you're right that the current tests only exercise the happy path. I'll send the split PRs (Signature and Encryption) soon and make sure to include the negative cases you listed: tampered signature rejection, wrong-key verification failure, wrong-key decryption failure, and truncated/corrupted encapsulation rejection.
   
   And yes, any help/contribution is welcome — feel free to jump in on either PR once they're up.
   
   Cheers
   Freeman


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]