Andrea Cosentino created CAMEL-24440:
----------------------------------------
Summary: 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
Fix For: 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)
