Crypto++ AEAD APIs accept zero-length authentication tags and report modified ciphertext as valid #1364

Summary

Two public Crypto++ AEAD interfaces accept an authentication-tag length of zero:

1. GCM<AES> through the filter API, where
   AuthenticatedEncryptionFilter and AuthenticatedDecryptionFilter accept
   truncatedDigestSize = 0.
2. ChaCha20Poly1305 through the one-shot API, where
   EncryptAndAuthenticate and DecryptAndVerify accept macSize = 0.

In both zero-length cases, encryption succeeds with a zero-length authentication output. After one ciphertext byte is modified, the corresponding decryption/verification operation still reports successful authentication for the modified ciphertext.

This report is specifically about accepting zero-length AEAD authentication outputs. It is not objecting to ordinary nonzero tag/MAC truncation if Crypto++ intentionally supports that API.

Tested version

Crypto++ master commit: fe62c6a03c69fb322faf282c6f69b0b0f0d965eb
Crypto++ release tag: CRYPTOPP_8_9_0
Crypto++ release commit: 843d74c7c97f9e19a615b8ff3c0ca06599ca501b

The reproducer was run against both the current master commit and the 8.9.0 release commit; both produced the output below.

Minimal reproducer

A minimal standalone reproducer is attached:

• repro.cpp
• build.sh
• run.sh

build.sh
repro.cpp
run.sh

The reproducer includes a normal 16-byte tag control for each API surface. In those controls, the same one-byte ciphertext modification is rejected, which checks that the decrypt/verify flow and mutation location are valid. It does not use a fuzzing harness, adapter layer, private API, or undefined behavior. The keys, nonces/IVs, AAD values, and plaintexts are fixed test values.

Build and run

The checked repro can be built and run with:

# Set this to a clean checkout of the version being tested.
export CRYPTOPP_ROOT=/path/to/cryptopp
./build.sh
./run.sh

build.sh accepts CRYPTOPP_ROOT when a different local Crypto++ tree is needed and writes the temporary executable under ${TMPDIR:-/tmp}.
For the current-master run, CRYPTOPP_ROOT pointed to a clean checkout of fe62c6a03c69fb322faf282c6f69b0b0f0d965eb.
The same commands were then run with CRYPTOPP_ROOT set to the clean CRYPTOPP_8_9_0 checkout for the release control.

Observed behavior

Output from the attached reproducer (the current-master run; the 8.9.0 run is identical):

row,library,primitive,api,parameter,value,encrypt_accepted,effective_tag_len,verification_result,modified_ciphertext_accepted,result
case,Crypto++,AES-GCM,AuthenticatedEncryptionFilter/AuthenticatedDecryptionFilter,truncatedDigestSize,0,true,0,true,true,zero_tag_issue_observed
case,Crypto++,AES-GCM,AuthenticatedEncryptionFilter/AuthenticatedDecryptionFilter,truncatedDigestSize,16,true,16,false,false,valid_tag_control_passed
case,Crypto++,ChaCha20-Poly1305,EncryptAndAuthenticate/DecryptAndVerify,macSize,0,true,0,true,true,zero_tag_issue_observed
case,Crypto++,ChaCha20-Poly1305,EncryptAndAuthenticate/DecryptAndVerify,macSize,16,true,16,false,false,valid_tag_control_passed
summary,affected_cases,2

effective_tag_len is measured from the GCM ciphertext and plaintext sizes. For ChaCha20-Poly1305 it records the requested macSize, because the one-shot API does not return a separate tag-length value.

Expected behavior

The affected AEAD interfaces should reject a requested authentication-tag length of zero before processing the message. Existing support for nonzero tag truncation is outside the scope of this report.

This expectation is also grounded in the published parameter domains: NIST SP 800-38D section 5.2.1 lists the permitted GCM tag lengths and does not include zero, while RFC 8439 section 2.8 defines the ChaCha20-Poly1305 authentication tag as 128 bits.

Related issues

Crypto++ issue #954 concerns oversized AES-GCM tag sizes and the resulting out-of-bounds behavior. This report is distinct: it concerns zero-length authentication outputs being accepted across the GCM filter API and the ChaCha20-Poly1305 one-shot API.