BLAKE2b produces wrong tag when using `reset()` with a different-length key

published 2026-10-30 9 d ago modified 2026-10-30 9 d ago also RUSTSEC-2026-0428

cvss: —; not scored
cisa kev: Not listed; not in CISA's catalog
epss: —; no score, EPSS covers CVEs only
public exploits: 0; none known

## Summary

`hazardous::mac::blake2b::Blake2b::reset()` does not correctly reset the state when a key is supplied that has a different length than the one used upon initialization with `hazardous::mac::blake2b::Blake2b::new()`, because it errorneously uses a cached length.

## Impact

Initialization `hazardous::mac::blake2b::Blake2b` with a key of some length `N`, followed by a reset with a key of length `!= N` will produce an incorrect BLAKE2b tag, causing `hazardous::mac::blake2b::Blake2b::verify()` to fail. This means under honest protocol conditions, parties could experience failing tag verifications.

## Resolution

Upgrade to `v0.17.16` or `v0.18.1`.

Patch / fix

fixed in 1 links 1

crates.io orion 0.17.16, 0.18.1

github.com/orion-rs/orion#690 pull request

Affected packages

ecosystem	package	affected	fixed in
crates.io	orion	>=0.0.0-0, <0.17.16 >=0.18.0-0, <0.18.1	0.17.16 0.18.1

References

github.com /orion-rs/orion/pull/690
web
crates.io /crates/orion
package
rustsec.org /advisories/RUSTSEC-2026-0428.html
advisory

Sources

OSV RUSTSEC-2026-0428

Fencer Vulns keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.