From 724940f79ead4a9bbd7294e4e1e310fd22e0db31 Mon Sep 17 00:00:00 2001 From: Thai Duong Date: Thu, 18 Jun 2026 01:08:52 +0700 Subject: [PATCH] Clarify one-byte tag forgery wording Co-Authored-By: Claude Opus 4.8 (1M context) --- MADBugs/ciphertext-format/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/MADBugs/ciphertext-format/README.md b/MADBugs/ciphertext-format/README.md index 106ae31..8889206 100644 --- a/MADBugs/ciphertext-format/README.md +++ b/MADBugs/ciphertext-format/README.md @@ -32,7 +32,7 @@ OpenSSL takes `aes-ICVlen` at face value and passes it to the AEAD as the expect wolfSSL got there by a different route. It ignores `aes-ICVlen` entirely and uses the length of the `mac` field as the tag length, so you leave the parameter alone and re-encode the `mac` octet string as `04 01 XX`, a one-byte string, and the receiver again checks a single byte. -Either way, a one-byte tag lets an attacker forge a valid message by brute force with probability 1/256 per attempt, which online is no protection at all. +Either way, a one-byte tag lets an attacker forge a valid message by brute force with probability 1/256 per attempt, which is no protection at all against anyone who can keep submitting messages. Bouncy Castle manages to be both better and worse. Its GCM engine has a hard floor of 4 bytes, so for AES-GCM the attacker can't get below a four-byte tag. But CMS also allows AES-CCM, which carries the same `aes-ICVlen` field, and Bouncy Castle's CCM engine only validates the tag length on *encrypt*. On decrypt the range check is skipped entirely, and even `aes-ICVlen = 0` is accepted.