[PR] Reject malformed HKDF Salt and Info with XMLEncryptionExc eption [santuario-xml-security-java]

Arpan0995 opened a new pull request, #653:
URL: https://github.com/apache/santuario-xml-security-java/pull/653

   On the decrypt path of an ECDH-ES (or X25519/X448) key agreement, the HKDF `Salt` and `Info` elements of the `KeyDerivationMethod` are read from the message and base64-decoded in `XMLCipherUtil#constructKeyDerivationParameter`. Malformed base64 in either element throws the `IllegalArgumentException` from `Base64.Decoder`, which escapes the `XMLEncryptionException` that `XMLCipher#decryptKey` declares. A caller handling the declared exception type therefore does not catch it, and on a service decrypting untrusted XML the malformed input surfaces as an uncaught error rather than a clean rejection. Reproduced on `main` with a secp256r1 ECDH-ES round trip and a mutated `Salt` or `Info`; the only pre-condition is a message the recipient is willing to decrypt, and the failure happens before t
 he key agreement is attempted.
   
   **The change.** Wrap the two decodes in a small helper that reports the failure as `XMLEncryptionException` using the existing `KeyDerivation.InvalidParameter` message (`Key derivation parameter {0} is illegal`), naming the offending element. The same strict `Base64.getDecoder()` is used, so well-formed input is unaffected.
   
   **Test.** `XMLCipherKeyAgreementMalformedHKDFParamsTest`: a positive control (the round trip decrypts with well-formed parameters) and a parameterized case for a malformed `Salt` and a malformed `Info`, each asserting `XMLEncryptionException` from the full decrypt path. It runs on the default profile with the JDK's EC provider, no BouncyCastle needed. I confirmed the test is not vacuous by running it against the unchanged code: the positive control passes and both malformed cases fail with the raw `IllegalArgumentException: Illegal base64 character`.
   
   **Verification.** `mvn test` over the new class and `XMLCipherTest` (which covers the ECDH-ES, X25519 and X448 key-agreement round trips): 40 executions, no regressions.
   
   For context, I found this while looking at the pending ML-KEM key-transport work (#652), which reaches the same code through a new path; the ECDH-ES path is affected on `main` today, so it seemed right to fix it here independently. The same guard is included in that branch via ffang/santuario-xml-security-java#6 and can be dropped there on rebase once this lands.
   


-- 
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]