If the author is here: thanks for that, interesting read, and also nice to note the absence of a marketing name for the bugs. If you have time, couple (edit: three) questions:
1. Could you expand on this? "That human-in-the-loop step still matters a lot, because AI candidate findings are cheap while trustworthy reports are not."
Roughly how many candidate reports did the LLMs create vs the eventual 7 true vulnerabilities?
2. As I was reading "CP-ABE access-control break via AND-share bug" I thought "why wasn't this caught with a test?", which was going to be my question but clicking through to the commit (thanks for that too btw) I see there was a regression test added: https://github.com/cloudflare/circl/commit/def2fd35b8535b0b8...
but I'm wondering why there isn't a test further up the stack that is simply checking "can't decrypt if the required attribute isn't present"? Seems similar to those situations where nobody thought to test an auth system for "user can't log in when they present the wrong password"!! Perhaps I'm missing some subtlety though.
3. This is probably a dumb question, but I wasn't sure (even after reading the linked article on zkao) exactly what zkao actually is. One description seems to be "a system for continuously running an LLM audit pass on a codebase". But that can't be right because this article talks about running it on the LLM-found vulnerability reports. Is it an LLM? (but better than the frontier LLMs?) Anyway, bit confused and would appreciate some clarity.
I work on www.zkao.io so I can expand on this: it's basically like an audit, you click a button and ~9h later you get a report with findings. It's supposed to be better at finding bugs (especially cryptographic bugs) than frontier models AND it's supposed to be better at discarding false positives.
I mean I know djb managed at some point to coax an x86 CPU floating point unit to perform weird integer operations to speed up some of his algorithms, but I would never have expected people to use floats the "intended way" to implement crypto algorithms.
It really should have been defined in terms of fixed point like HAWK was. The floating point choice has so many implementation issues and it's hard to see what advantage Falcon really gains from it besides making a few operations easier to specify (just not in constant time).
> how it's require to hand-implement floats to get constant-time operations.
That and not be at the mercy of someone changing the current rounding mode behind your back.
Also hand-implement floats ... not likely to be particularly efficient, no ?
I took a quick glance at the section "About those floating points". Whomever designed that algorithm used the biggest footgun ever. I mean floating point numbers? For crypto?
Even if he can mathematically prove is algorithm is solid, he's going to lose 99% of his intended audience the moment he's going to use the words crypto and floating point in the same sentence.
Im not a security engineer at all and I have an instant gut reaction to floats in regular code. ”How big can this get? Is it deserialized? What arithmetic ops are happening? Any risk of rounding error propagation?” etc.
Now, I wouldn’t necessarily mean I deem it bad practice in security contexts since again, I don’t know. But if an expert doesn’t consider those things, I would be surprised (and a little scared).
1. Could you expand on this? "That human-in-the-loop step still matters a lot, because AI candidate findings are cheap while trustworthy reports are not." Roughly how many candidate reports did the LLMs create vs the eventual 7 true vulnerabilities?
2. As I was reading "CP-ABE access-control break via AND-share bug" I thought "why wasn't this caught with a test?", which was going to be my question but clicking through to the commit (thanks for that too btw) I see there was a regression test added: https://github.com/cloudflare/circl/commit/def2fd35b8535b0b8... but I'm wondering why there isn't a test further up the stack that is simply checking "can't decrypt if the required attribute isn't present"? Seems similar to those situations where nobody thought to test an auth system for "user can't log in when they present the wrong password"!! Perhaps I'm missing some subtlety though.
3. This is probably a dumb question, but I wasn't sure (even after reading the linked article on zkao) exactly what zkao actually is. One description seems to be "a system for continuously running an LLM audit pass on a codebase". But that can't be right because this article talks about running it on the LLM-found vulnerability reports. Is it an LLM? (but better than the frontier LLMs?) Anyway, bit confused and would appreciate some clarity.
Wow.
I mean I know djb managed at some point to coax an x86 CPU floating point unit to perform weird integer operations to speed up some of his algorithms, but I would never have expected people to use floats the "intended way" to implement crypto algorithms.
https://keymaterial.net/2026/05/13/so-you-want-to-deploy-fn-... talks about FN-DSA and has a section about how it's require to hand-implement floats to get constant-time operations.
That and not be at the mercy of someone changing the current rounding mode behind your back.
Also hand-implement floats ... not likely to be particularly efficient, no ?
I took a quick glance at the section "About those floating points". Whomever designed that algorithm used the biggest footgun ever. I mean floating point numbers? For crypto?
Even if he can mathematically prove is algorithm is solid, he's going to lose 99% of his intended audience the moment he's going to use the words crypto and floating point in the same sentence.
Now, I wouldn’t necessarily mean I deem it bad practice in security contexts since again, I don’t know. But if an expert doesn’t consider those things, I would be surprised (and a little scared).
https://github.com/cloudflare/circl/commit/f7d2180d6a77cfb28...