[
https://issues.apache.org/jira/browse/CAMEL-24440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18124912#comment-18124912
]
Claus Ibsen commented on CAMEL-24440:
-------------------------------------
Merged to main: https://github.com/apache/camel/pull/27504 (4.23.0). Kept open
for the backport to 4.22.x. _Claude Code on behalf of davsclaus_
> camel-crypto - CryptoDataFormat validates the MAC after decrypting, reuses
> the cipher key for the HMAC, and has no per-message IV
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: CAMEL-24440
> URL: https://issues.apache.org/jira/browse/CAMEL-24440
> Project: Camel
> Issue Type: Bug
> Components: camel-crypto
> Reporter: Andrea Cosentino
> Assignee: Andrea Cosentino
> Priority: Major
> Fix For: 4.22.2, 4.23.0
>
>
> Four related issues in {{CryptoDataFormat}}:
> 1. *MAC checked after decryption.* {{unmarshal()}} runs the body through
> {{CipherInputStream}} to completion before {{HMACAccumulator.validate()}} is
> called. Tampered input therefore surfaces as two distinguishable failures -
> {{IOException}} (bad padding, from the cipher) versus
> {{IllegalStateException}} (bad MAC) - rather than one uniform authentication
> failure.
> 2. *Key reuse.* {{HMACAccumulator}} is constructed with the HMAC key derived
> from the same {{key.getEncoded()}} used for the cipher. The same key material
> is used for both confidentiality and integrity.
> 3. *MAC values in the failure message.* {{HMACAccumulator.validate()}} builds
> its exception message with both the expected and the computed MAC in hex.
> 4. *No per-message IV.* {{getInitializationVector()}} returns the header
> value or the statically configured {{initVector}}; nothing ever generates a
> fresh one. {{marshal()}} even throws when {{inlineInitVector=true}} and no
> static IV was configured, which steers users towards a fixed IV for exactly
> the feature that exists to carry a per-message one. The javadoc notes the IV
> need not be secret but never that it must be unique.
> Proposal: derive separate cipher and MAC keys from the configured key (HKDF
> or equivalent); validate the MAC before releasing plaintext, or move to an
> AEAD mode; report a single uniform authentication failure without embedding
> MAC values; and generate a per-message {{SecureRandom}} IV when
> {{inlineInitVector}} is enabled instead of requiring a static one. Changing
> key derivation or IV handling breaks compatibility with data produced by
> earlier versions, so it needs an upgrade-guide entry and probably a version
> marker in the output format.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
