GHSA-3g97-82p7-9p2w: 
Rust vulnerability analysis and mitigation

Impact

Several kyberlib types that hold secret material derived Debug, so formatting one with {:?} or {:#?} writes the secret bytes to the output:

Affected versions

Checked by downloading every published .crate from crates.io and reading the derive on each type, and by git grep on the tags.

Reproduction

use kyberlib::{keypair, Uake};
fn main() {
    let mut rng = rand::thread_rng();
    let keys = keypair(&mut rng).unwrap();
    // Prints every secret key byte.
    println!("{keys:?}");
    let mut alice = Uake::new();
    alice.client_init(&keys.public, &mut rng).unwrap();
    // Prints the ephemeral secret key (eska) and temp_key.
    println!("{alice:?}");
}

Patches

Fixed in kyberlib 0.0.11 and kyberlib-wasm 0.0.11. Each type now implements Debug by hand and prints secret buffers by length only, for example:

Keypair { public: [1184 bytes; not secret], secret: [REDACTED 2400 bytes] }
Uake { shared_secret: [REDACTED 32 bytes], send_a: [2272 bytes; not secret], send_b: [1088 bytes; not secret], temp_key: [REDACTED 32 bytes], eska: [REDACTED 2400 bytes] }

(sizes shown for ML-KEM-768). 0.0.11 also derives Zeroize and ZeroizeOnDrop on Uake and Ake, so their secrets are cleared when the value is dropped. Upgrade with cargo update -p kyberlib -p kyberlib-wasm.

Workarounds

If you cannot upgrade yet:

• Do not format any of the types above with Debug, and do not put one inside a type that derives Debug and is logged.
• Wrap them in a newtype with a hand-written Debug that omits the secret fields.
• Move from Keypair to the typed API (MlKem768::generate, MlKem768DecapKey), whose Debug output is already redacted.
• Search existing logs for Keypair {, Keys {, Uake {, Ake {, Kex {, KeccakState { and Aes256CtrCtx {. Treat any long-term key that appears there as compromised: generate a new keypair and retire the old one. A leaked session secret cannot be revoked; treat the traffic of that session as disclosed.

Credit

Found during an internal review of the kyberlib.com rebuild.

Severity

CVSS 3.1 for the advisory (the highest of the affected types): CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:N/A:N (4.7, Medium)

• Keypair, wasm Keys (long-term secret key): 4.7, the vector above. The key is exposed only if the application logs the value and the attacker can read those logs (local access, high complexity, low privileges); the result is full loss of confidentiality for everything sent to that key, and no integrity or availability impact.
• Uake, Ake, wasm Kex (one exchange's secrets): CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N (2.5, Low). Same preconditions, but the secrets are ephemeral, so a leak discloses one session and no long-term key.
• KeccakState, 90s XofState: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N (2.5, Low). kyberlib never exposes its own internal states, so only data a caller absorbs into a state it created and then logs is at risk.