Skip to content
Patch Next
Sign inAdd to your agent

← Public intelligence

crates.io package

ic-cipher

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

1 actionable advisory, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. High, CVSS 7.5crates.ioPublished

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

    GHSA-xr22-8pqp-gwfh

    Affected
    • crates.io ic-cipher >= 0.2.5, < 0.2.20
    Fixed in
    0.2.20· Vendor fix available
    Issue
    `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: - With overflow checks on (any debug build, or a release profile with `overflow-checks = true`) the multiplication panics, and under `panic = "abort"` the process ends. The tag is computed over the ciphertext before it is compared, so this happens before authentication and without the key: anyone who can deliver a ChaCha20-Poly1305 ciphertext to be opened can trigger it. - With overflow checks off (Cargo's default for release builds) the…

    Recommended action: Upgrade to 0.2.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.devSource checked Evidence →