The technical "problem" depends on whether you view security through the lens of mathematical purity or practical risk. Both sides have valid technical arguments, but they are talking past each other.
1. The Nonce-Reuse Bug (hpke-rs)

* The Flaw: As discussed, the AES-GCM nonce counter in hpke-rs can wrap around after $2^{32}$ operations.
* Is it a "Problem"?
* Technically: Yes. In cryptography, reusing a nonce with AES-GCM is a "catastrophic" failure that allows an attacker to decrypt traffic and forge messages.
* Practically: Unlikely. For a typical application, performing 4.2 billion encryptions on a single session key is rare. Most high-security protocols (like TLS or Signal) re-key far earlier.
* The Fix: Cryspen patched this by adding a check to ensure the counter never overflows. [1, 2, 3, 4]

2. The DoS/Panic Bug (libcrux-psq)

* The Flaw: A specific malformed AES-GCM ciphertext could trigger a panic! in libcrux-psq during decryption.
* Is it a "Problem"?
* Technically: Yes. This was formally issued as [RUSTSEC-2026-0025](https://rustsec.org/advisories/RUSTSEC-2026-0025) with a CVSS score of 8.2 (High).
* Practically: Yes. A remote attacker could crash a server by simply sending a "poison" packet.
* The Fix: The vulnerability was addressed in libcrux PR #1319. [5]

3. The "Unverified Fallback" (libcrux-intrinsics)

* The Flaw: On certain ARM platforms, an "unverified fallback" code path produced incorrect SHA-3 results, leading to invalid digital signatures.
* Is it a "Problem"?
* Technically: Yes. It was issued as RUSTSEC-2025-0133.
* Practically: Moderate. It causes "functional failure" (the crypto just doesn't work), which is a major issue for a library marketing itself as "formally verified". [6, 7, 8, 9, 10]

Summary Assessment

| Feature | Kobeissi's View (Researcher) | Maintainers' View (Developer) |
|---|---|---|
| Severity | Critical: Any crypto break is a failure. | Low/Moderate: These are edge cases or pre-release bugs. |
| Disclosure | Mandatory: Use cargo audit to alert everyone. | Discretionary: Fix silently if the risk is low to avoid "noise." |
| Verification | Failed: The "verified" claim is misleading. | Working: Verification is a process; bugs are found in unverified shims. |

The verdict: These are legitimate technical bugs. The "war of words" is not about whether the bugs exist, but about communication. Kobeissi is right that users deserve advisories for breaking crypto; the maintainers are right that his approach was perceived as inflammatory for low-probability risks.
Would you like to see the specific code diff for the nonce-reuse fix to see how they implemented the counter check?

[1] [https://www.theregister.com](https://www.theregister.com/2026/03/20/cryptographer_nadim_kobeissi_rustsec_ban/?td=keepreading#:~:text=Not%20everyone%20agrees%20with%20that%20assessment.%20Cryptographer,what%20in%20my%20opinion%20was%20unobjectionable%20behavior.%22)
[2] [https://rustsec.org](https://rustsec.org/advisories/RUSTSEC-2025-0009.html)
[3] [https://github.com](https://github.com/advisories/GHSA-g433-pq76-6cmf#:~:text=Description.%20We%20publish%20a%20GitHub%20security%20advisory,and%20hpke%2Drs%2Drust%2Dcrypto%20crates%20contain%20the%20following%20bug%2Dfixes:)
[4] [https://github.com](https://github.com/cryspen/hpke-rs#:~:text=An%20implementation%20of%20HPKE%20%28RFC%209180%29%20with,authenticate%20possession%20of%20a%20KEM%20private%20key.)
[5] [https://rustsec.org](https://rustsec.org/advisories/RUSTSEC-2026-0025)
[6] [https://lobste.rs](https://lobste.rs/s/vhvbr8/on_promises_high_assurance_cryptography#:~:text=On%20platforms%20without%20the%20core::arch::aarch64::vxarq_u64%20intrinsic%2C%20an,yielding%20incorrect%20shared%20secrets%20and%20invalid%20signatures.)
[7] [https://rustsec.org](https://rustsec.org/categories/crypto-failure.html)
[8] [https://rustsec.org](https://rustsec.org/categories/crypto-failure.html)
[9] [https://github.com](https://github.com/cryspen/libcrux)
[10] [https://crates.io](https://crates.io/crates/libcrux)