CIRCLE WITH A DOT

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)

Cryptographer fights RustSec ban over bug reports • The Register ~ What’s your take? Critical or not?

Cryptographer fights RustSec ban over bug reports

Updated: Rust security maintainers contend Nadim Kobeissi's vulnerability claims are too much

(www.theregister.com)

AI Model DNS Leaks
Is this really a bug? Or is it functionality abuse? Because this is how the internet works. You decide. In any case be aware...

https://teriradichel.substack.com/p/ai-model-dns-leaks

RE: https://infosec.exchange/@teriradichel/116189065717578221

Latest - building my whole batch job framework with AI now. Obviously going to need a lot of review. But will allow me to run my pentesting jobs more easily on new targets and pentests. I already have some new pentesting jobs written will talk about in April at AWS security community event in Mountain View. More on that later.

A Script To Monitor Application Network Connections How would you spot a reverse shell such as was used in Lexus Nexus breach? I vibe coded this script to see parent and child processes with application paths, process names, IPs, ports, IN or OUT.

I combined output from different tools to make an easier to read format. You’d want to use a different script to detect beaconong and it won’t catch everything but it’s still a good way to spot things that shouldn’t be on your network at a glance.

https://teriradichel.substack.com/p/a-script-to-monitor-application-network

I swear I’m posting things on Mastodon and they are getting deleted or just never showing up. Hmmm….

@briankrebs you 100% cannot trust it. Like Google search results and Wikipedia. But it still might give you some idea or thought or resource you hadn’t seen yet that you can go research further. It can help you think of new questions and point you in new directions (which can be good or bad). I use it to explore ideas and if I do copy something written by AI I write “from Google AI:” or whatever so people can take it with a grain of salt and can back that up with links to other sources. It’s usually something I know is right but I like the way it wrote it and saves me some time. Sometimes I call out when it is wrong to demonstrate why you can’t always trust it. But I’m researching and writing about AI not the kind of things you write about so it’s a bit different. I generally just cite sources if I’m writing something about a data breach like you (and nowhere near the deep dive you do!)