Cryspen’s co-founder Karthikeyan Bhargavan told The Register last week:

we did not do great with these advisories.

You can say that again.

Nadim Kobeissi, an applied cryptographer, found thirteen vulnerabilities in Cryspen’s libcrux and hpke-rs libraries. He published the findings in an IACR ePrint paper titled “Verification Theatre.” Nine of the bugs were in unverified code. Four were inside the formally verified boundary, which means the code Cryspen markets as providing “the highest level of assurance.”

This is actually a big deal.

Cryspen built Signal’s post-quantum ratchet (SPQR) using libcrux’s ML-KEM implementation. Their own website states the implementation is:

formally verified for panic-freedom, functional correctness, and secret independence, and hence provides a high degree of assurance.

One of Kobeissi’s bugs caused real decryption failures in that implementation (a cross-backend endianness error). Signal’s signal-crypto crate depends directly on hpke-rs, where the nonce-reuse vulnerability lives.

The nonce-reuse bug enables full AES-GCM plaintext recovery and forgery after 2^32 encryptions with a single HPKE setup.

There’s also a missing mandatory X25519 validation required by RFC 9180, ECDSA signature malleability, an Ed25519 key generation defect, a denial-of-service via unhandled AES-GCM decryption, and two FIPS 204 specification violations in the ML-DSA verifier.

At this point you might expect Kobeissi to be given respect for his work. He clearly has gone above and beyond in helping consumers of these libraries (Signal, OpenMLS, Google, and components touching the Linux kernel and SSH).

Cryspen told The Register these bugs “were addressed within a week”, optimizing their message around speed rather than assurance. They then claimed no bugs had been found in their verified code. Kobeissi’s paper in fact documents four.

Here’s where it gets interesting.

RustSec is the advisory database for the Rust ecosystem. When you run cargo audit, it checks your dependencies against RustSec. If they refuse to add an advisory, you get a false clean audit. Your CI passes when it should stop. Your security review finds nothing. Every automated tool in the ecosystem treats a vulnerability as if it doesn’t exist.

Kobeissi filed advisory pull requests with RustSec for the nonce-reuse and denial-of-service vulnerabilities. The RustSec maintainer went passive aggressive and closed the pull requests without any technical justification.

You might say this is just sloppy or rushed work, but then the researcher was silently blocked from the RustSec GitHub organization without notice. His pending pull request was closed after he was blocked, if you catch the drift here. Someone felt shame, embarrassment even, and wanted to erase the truth.

One Register commenter reported:

The bugs are real, and easily fixed — but I’ve absolutely no idea whether the version I’m using is fixed or not, because they refused to publish an advisory.

That’s not a good sign.

I’ve been researching and writing about systems integrity failure for decades. The pattern is simple: the system that’s supposed to admit the problem is captured by the people who produced it, who are incentivized to hide. The advisory database is allegedly set up for it to be cheaper to suppress the report than to deal with what it would say. That unfairly transfers risk externally to people who don’t even know.

Kobeissi then logically filed a complaint with the Rust Moderation Team and Leadership Council about the RustSec maintainer’s conduct. The result confirmed an integrity breach of the RustSec system. Five hours later he was banned from Rust Project Zulip spaces.

He then escalated to the Rust Foundation. In his complaint he identified the structural problem: the Rust Project’s moderation team representative on the Leadership Council is the same individual who issued a public moderation warning against him in the underlying advisory dispute.

He is both a participant in the conduct I am complaining about and a member of the body responsible for reviewing that conduct.

This is true. And thus an integrity breach.

The Rust Project’s own governance documents say council representatives have an obligation:

must promptly disclose conflicts of interest and recuse themselves from affected decisions.

The Rust Foundation’s own conflict of interest policy says a covered official:

whose potential conflict is under review may not debate, vote, or otherwise participate in such determination.

Neither happened.

This apparently isn’t new for Rust. I researched their integrity issues and found in November 2021 the entire Rust moderation team resigned over “the Core Team placing themselves unaccountable to anyone but themselves.”

Their letter said they had been “unable to enforce the Rust Code of Conduct to the standards the community expects.” They recommended the community “exercise extreme skepticism of any statements by the Core Team.”

The Leadership Council was created in response. It was supposed to fix the accountability problem. What it actually created was another layer where the people being complained about adjudicate the complaints.

Filippo Valsorda, a cryptographer known for drama with Kobeissi for over a decade, tried to get a dig into The Register, telling them:

looks more and more to him like the harassment of open source maintainers.

More and more? That phrase isn’t working. There’s less and less evidence of harassment as the vulnerabilities are proven accurate. He also said the nonce-reuse bug “seems to be a valid security issue.” But from that he incorrectly concluded if RustSec banned Kobeissi, “he’s inclined to believe they had reason to do so.” He means he would like to believe that, as a personal matter. He gives exactly zero reasons, or even tries to name them.

It’s circular. The question is whether the reasons were technical or political. The pull requests were closed without technical justification. The ban message cited “harassment”. Really? The same word used to dismiss the advisory contributions, imposed by the same people whose conduct was being complained about. How convenient for them.

The “harassment” label doesn’t pass even a basic test. It converts a dispute about whether acknowledged cryptographic vulnerabilities deserve public advisories into tone shaming. Once you’re arguing about tone, the institution automatically shuts down security. It controls the standards, the process, and the enforcement. The same people who refused to publish the advisory get to decide whether asking them to publish it constitutes harassment.

It obviously was the opposite of harassment. Extremely high quality professional work was delivered.

Kobeissi is a cryptographer who found real bugs in real libraries used by billions of people, published a paper clearly documenting them, and followed the correct disclosure process. For that he’s been vilified by a system designed to block, ban, and label research to avoid facing the truth.

Every developer running cargo audit against a dependency with a known nonce-reuse vulnerability is getting a false result right now.

That’s an integrity breach.