RustSec logo

History ⋅ Edit ⋅ JSON (OSV)

RUSTSEC-2026-0337

Poly1305 panics or computes a wrong tag on attacker-chosen messages of 64 bytes or more

Reported
Issued
Package
ic-cipher (crates.io)
Type
Vulnerability
Categories
Keywords
#poly1305 #chacha20-poly1305 #integer-overflow
Aliases
References
CVSS Score
7.5 HIGH
CVSS Details
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality Impact
None
Integrity Impact
None
Availability Impact
High
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Patched
  • >=0.2.20
Unaffected
  • <0.2.5

Description

Poly1305 in ic-cipher absorbs messages of 64 bytes or more four blocks at a time, summing four products before one reduction. From 0.2.5 to 0.2.19 the reduction kept its carries in 32-bit integers, which four summed products can overflow when the message's bytes are large.

This affects Poly1305 and ChaCha20Poly1305, and everything built on them: the TLS and QUIC ChaCha20-Poly1305 suites in ic-rustls, HPKE with that cipher in ic-hpke, and the re-exports in ic-mac and ironcrypto.

What happens depends on how the crate was compiled:

Ordinary data does not reach the defect. A message of 0xff bytes does: in one measurement against 0.2.19, 28 of 500 ChaCha20Poly1305::open_detached calls on 1,024 bytes of 0xff under random keys and nonces panicked in a debug build. ChaCha20-Poly1305 derives a new Poly1305 key for every nonce, so each message is a fresh attempt.

AES-GCM and AES-GCM-SIV are not affected, and neither are messages shorter than 64 bytes.

The flaw was corrected in 0.2.20 by carrying in 64 bits.

It was found by running Project Wycheproof's ChaCha20-Poly1305 test vectors against the library.

Advisory available under CC0-1.0 license.