GHSA-xcc6-f2jq-43x6: 
Rust vulnerability analysis and mitigation

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 erroneously uses a cached length.

Details

No additional details.

Proof of concept

#[test] fn test_reset_uses_correct_key() { let message = b"message"; let taglen = 3;

let k1_32 = SecretKey::try_from(&[0x11; 32]).unwrap();
let k2_32 = SecretKey::try_from(&[0x33; 32]).unwrap();
let k3_33 = SecretKey::try_from(&[0x22; 64]).un

let mut mac = Blake2b::new(&k1_32, taglen).unwrap();
mac.update(message).unwrap();
let t1 = mac.finalize().unwrap();
assert!(Blake2b::verify(&t1, &k1_32, taglen, message).is

mac.reset(&k2_32).unwrap();
mac.update(message).unwrap();
let t2 = mac.finalize().unwrap();

// Length is cached, so same length reset worked.
assert!(Blake2b::verify(&t2, &k2_32, taglen, message).is_ok());
assert_eq!(t2.unprotected_as_ref(), &hex::decode("c053d9657b3d5e0b8ecc62235f25936008981da8f8ae9456e5fe2517a1b65153").unw

// Reset to a different-length key.
mac.reset(&k3_33).unwrap();
mac.update(message).unwrap();
let t3 = mac.finalize().unwrap();
assert!(Blake2b::verify(&t3, &k3_33, taglen, message).is_ok());
assert_eq!(t3.unprotected_as_ref(), &hex::decode("fa0e4d6c7974a2021f96f30e98e8564430441e460f32e98de2cea59c320271d5").unw
// ^^^ fails

}

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.