High Assurance, Low Availability: The Libcrux Triple Threat

There is a delicious irony in finding basic implementation bugs in software marketed as 'High Assurance.' libcrux is designed to be the Fort Knox of cryptography, using formal verification to prove correctness. It’s the kind of library you use when you don't trust standard OpenSSL implementations. But verification often proves that the code matches a specification, not that the specification—or the glue code around it—is sane.

In early 2026, researchers at Symbolic Software popped the hood on libcrux and found three glaring issues that range from 'cryptographically annoying' to 'operationally fatal.' The most embarrassing? A classic Rust newbie mistake: handling fallible operations with a panic.

While the cryptographic math might have been sound in a vacuum, the implementation committed the cardinal sin of systems programming: assuming inputs will always be well-formed. This report dissects how a library built for safety left the door open for a cheap Denial of Service and generated keys that looked correct but were mathematically isolated from the rest of the RFC-compliant world.

This vulnerability isn't one bug; it's a trench coat containing three smaller bugs standing on each other's shoulders.

1. The Panic Button (DoS): In libcrux-psq, the library implemented AEAD (Authenticated Encryption with Associated Data). When decrypting data, the library must verify the authentication tag. If the tag is wrong (spoofed or corrupted), decryption fails. In Rust, you handle this with a Result. libcrux decided to handle it with .unwrap(). This means if an attacker sends any garbage data, the decryption returns an error, .unwrap() panics, and the entire application crashes. Unauthenticated, remote, instant kill.

2. The Clamping Confusion (Ed25519): Curve25519 requires 'clamping'—setting specific bits to ensure security properties. RFC 8032 says: take the 32-byte seed, SHA-512 hash it, then clamp the resulting scalar. libcrux got eager and clamped the seed before hashing it. This reduced the entropy of the seed (wasting 5 bits) and, critically, generated public keys that no other standard library (Sodium, OpenSSL, etc.) could reproduce from the same seed. It’s like speaking a dialect of English that only you understand.

3. The Impossible Check (X25519): The library tried to validate imported keys with the logic: if value[31] & 64 != 1. Let's do the math. value[31] is a byte. 64 is 0x40 (binary 01000000). A bitwise AND between any byte and 64 results in either 0 or 64. Neither of those is 1. The condition is logically nonsensical, leading to valid keys being rejected or accepted based on flawed premises.

Let's look at the diffs, because they paint a vivid picture of the oversight.

The DoS (AEAD Unwrap): Here is the culprit in src/aead.rs. The code was unwrapping the result of the decryption. If the ciphertext was tampered with, decrypt returns an Err, and unwrap sends the process to the graveyard.

// BEFORE (Vulnerable)
let plaintext = aead::decrypt(key, nonce, associated_data, ciphertext)
    .unwrap(); // <--- The self-destruct button
 
// AFTER (Fixed)
let plaintext = aead::decrypt(key, nonce, associated_data, ciphertext)
    .map_err(|_| Error::DecryptionFailed)?; // Propagate the error safely

The Logical Falacy (X25519 Check): The validation logic in libcrux-psq was trying to enforce bit settings but failed basic boolean logic.

// BEFORE (Broken Logic)
// 64 is 0x40. (x & 0x40) is either 0 or 64. It is never 1.
if value[31] & 64 != 1 {
    return Err(Error::InvalidKey);
}
 
// AFTER (Corrected)
// Checks if the 6th bit is set (which is 0x40)
if value[31] & 0x40 == 0 {
     return Err(Error::InvalidKey);
}

The Clamping Mix-up: The fix involved moving the bit-clearing operations to happen after the SHA-512 expansion, aligning the implementation with RFC 8032.

Exploiting the encryption flaws (clamping) is subtle and mostly results in broken interoperability. However, exploiting the AEAD panic is trivial and devastating for availability.

Target: A server using libcrux-psq to handle encrypted sessions (e.g., a secure handshake or VPN termination).

Attack Chain:

1. Recon: Identify the service is using libcrux (perhaps via banner grabbing or specific protocol behavior).
2. Weaponization: Construct a packet that looks like a valid encrypted message but contains a random, invalid authentication tag (MAC). You don't need the key; you just need to fail the integrity check.
3. Delivery: Send the packet to the listening port.
4. Execution:
   • The server receives the packet.
   • It calls aead::decrypt().
   • The Poly1305 (or equivalent) tag check fails.
   • The library returns Err.
   • The code calls .unwrap() on the Err.
   • SIGABRT. The server process terminates immediately.

This is an asymmetric attack. It costs the attacker one packet and zero CPU to crash a high-assurance system that might take seconds or minutes to restart.

The remediation is straightforward: upgrade the library. The flaws are implementation defects, not protocol weaknesses, so no configuration change will save you. You must replace the binary.

Steps:

1. Update libcrux crates to the latest version (released post-Feb 9, 2026).
2. Key Rotation (Crucial): If you generated Ed25519 keys using the vulnerable version, those keys are technically 'valid' curve points, but they are non-standard. If you try to import them into OpenSSL or Go's crypto library, they will likely derive a different public key or fail verification. You should regenerate these keys using the patched library to ensure RFC compliance.
3. Audit Dependents: Check any Rust code in your organization for unwrap() calls on cryptographic operations. This pattern is a plague. Use clippy or custom linting rules to ban .unwrap() in production network paths.