AI-generated analysisPublished automatically and not human-verified. Validated context appears in community notes below.
← Watch feed
Informational 24 Bitcoin

Add fuzzing support for chacha20_poly1305 via cfg flag

Public commit record

What the developer wrote

Authored by Abeeujah

85/100 · Strong
Add fuzzing support for chacha20_poly1305 via cfg flag

Introduce `chacha20_poly1305_fuzz` cfg to replace ChaCha20 and Poly1305
primitives with deterministic no-op implementations for fuzzing.

- ChaCha20: keystream returns zeroed 64-byte blocks; apply_keystream
is a no-op.
- Poly1305: stores first 16 bytes of key directly as the tag (trivial
construction avoiding crypto bottlenecks).
- AEAD: derives poly_key directly from raw key bytes, bypassing
ChaCha20 keystream entirely.
- Key: change visibility to pub(super).

Register cfg in workspace lints to prevent unexpected_cfg violations.
✓ Specific, descriptive subject✓ Names a concrete action or component✓ Provides detailed explanatory context✓ Explains rationale or failure mode
The short version

What changed, and why it matters

This commit adds a special build-time flag named `chacha20_poly1305_fuzz` that swaps out real ChaCha20/Poly1305 cryptography with fake, deterministic no-op versions intended only for fuzz testing. The fake versions do not encrypt data and do not authenticate it; they are meant to be used only when explicitly compiling with the fuzz flag. The change itself is a test/infrastructure addition, not a normal production code path. The main risk is accidental misuse: if someone builds or ships production code with `chacha20_poly1305_fuzz` enabled, encryption and authentication would be silently disabled. The commit does not claim to fix a vulnerability and does not appear to introduce one in normal builds.

Recommended action

Treat `chacha20_poly1305_fuzz` as a debug/test-only configuration. Ensure CI, release builds, and published crates never enable it. Consider adding a compile-time or documentation warning that the cfg disables all cryptographic security. Review any downstream packaging that might pass `--cfg chacha20_poly1305_fuzz` unintentionally.

Security signals we found

01

Conditional compilation replaces cryptographic primitives with no-op/deterministic stubs under `chacha20_poly1305_fuzz`

02

AEAD encryption path becomes identity transform and authentication tag becomes first 16 bytes of key when fuzz cfg is active

03

Key material is read directly from `Key.0` in fuzz path, requiring visibility change to `pub(super)`

04

Workspace lints updated to allow the new cfg, reducing build friction for fuzz targets

05

No production code path is modified when the cfg is absent

Risk score

Why this scored 24/100

Our methodology →
Potential impact 2/30
Exploitability 3/25
Stealth signal 4/15
Affected reach 3/15
Confidence 8/10
Evidence quality 4/5
Human-validated context

Community notes

Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.

No validated notes yet.

The AI analysis stands alone for now. Submit a note if you can add evidence or important context.