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.
The ability to decrypt depends on figuring out that the sharing scheme has your pieces covered, and knowing that you have in fact covered the right thing because of a bug like this is hard to do. There are some ways to test the sharing scheme that might have caught this, and looking at example shares carefully should have, but it's a bit more subtle to make generic tests.
Ok but my understanding from the article was that the bug is "it always allows what shouldn't be allowed", therefore any negative outcome test should have failed (or at least a very very simple one). Again I'm sure I'm misunderstanding something about the context here.
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. Supposedly you'd need a large number of bits for it, but I'm not sure I find that argument particularly convincing given that floats are a kind of fixed point in log space, with a bunch of asterisks that don't help falcon much.
As a follow-up to this comment, I sat down and implemented a better method myself, then looked at the specification code to discover they did exactly the same thing.
> 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).
Yes, this was a bit of a surprise to read when dealing with crypto: "This one lives in CIRCL's threshold RSA implementation... float64 has a 53-bit mantissa... the result is silently rounded before it is ever cast back to an integer. "
this is numerical methods 101, i.e. why 1+1 != 2
I'm a bit surprised that this is from cloudflare. Anybody from CF care to comment? Is this like prototype/super skunkworks code that somehow made it through?
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.
The ability to decrypt depends on figuring out that the sharing scheme has your pieces covered, and knowing that you have in fact covered the right thing because of a bug like this is hard to do. There are some ways to test the sharing scheme that might have caught this, and looking at example shares carefully should have, but it's a bit more subtle to make generic tests.
Ok but my understanding from the article was that the bug is "it always allows what shouldn't be allowed", therefore any negative outcome test should have failed (or at least a very very simple one). Again I'm sure I'm misunderstanding something about the context here.
People do crypto using floats these days?
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.
So, in this case it wasn't correct to do so, but there is actually a current algorithm which uses floating point: Falcon (aka FN-DSA).
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.
It really should have been defined in terms of fixed point like HAWK was. Supposedly you'd need a large number of bits for it, but I'm not sure I find that argument particularly convincing given that floats are a kind of fixed point in log space, with a bunch of asterisks that don't help falcon much.
As a follow-up to this comment, I sat down and implemented a better method myself, then looked at the specification code to discover they did exactly the same thing.
> 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.
Well, no. That's the bug. The fix is to "not do that", although one does wonder what the original author was smoking!
https://github.com/cloudflare/circl/commit/f7d2180d6a77cfb28...
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).
Yes, this was a bit of a surprise to read when dealing with crypto: "This one lives in CIRCL's threshold RSA implementation... float64 has a 53-bit mantissa... the result is silently rounded before it is ever cast back to an integer. "
this is numerical methods 101, i.e. why 1+1 != 2
I'm a bit surprised that this is from cloudflare. Anybody from CF care to comment? Is this like prototype/super skunkworks code that somehow made it through?
[flagged]