oscerd opened a new pull request, #26725:
URL: https://github.com/apache/camel/pull/26725

   This fixes [CAMEL-24440](https://issues.apache.org/jira/browse/CAMEL-24440) 
— three changes to `CryptoDataFormat`, none of which affects the format of data 
already written.
   
   **A per-message initialization vector when inlining.** `marshal` used to 
throw *"Inlining cannot be performed, as no initialization vector was 
specified"* when `shouldInlineInitializationVector` was set without a 
statically configured vector — which pushed routes into reusing one IV for 
every message, the very thing inlining exists to avoid. A fresh vector (sized 
to the cipher block length) is now generated per message when none is supplied; 
because it is written into the message, readers pick it up from the stream and 
need no change. An explicitly supplied vector (config or 
`CamelCryptoInitVector` header) is still used as given.
   
   **Authentication failures report uniformly.** A tampered message previously 
surfaced two distinguishable outcomes — `Given final block not properly padded` 
from the cipher (bad CBC padding) or `Expected mac did not match actual mac` 
from the MAC check. A caller who can submit ciphertext and observe which came 
back can use that distinction as a **padding-oracle** to recover plaintext, and 
the old MAC message even printed the computed `HMAC_k` over the just-produced 
plaintext. Both now report `Message authentication failed` with no MAC values. 
*Code matching on the old text must be updated* (upgrade guide entry included).
   
   **The inlined vector length is bounded.** The length prefix is read from the 
message and used to size an allocation; a declared length outside `0–1024` is 
now rejected rather than attempted.
   
   **Test:** `CryptoDataFormatIvAndFailureTest` covers the per-message IV, the 
uniform failure for both tampering modes, and the length bound.
   
   🤖 Generated with [Claude Code](https://claude.com/claude-code)
   


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

Reply via email to