> they only proved narrow properties of the system.

It's that, yes.

They didn't prove that the code has no bugs; they proved that none of the current bugs (known or unknown) are security-breaking bugs, per their formalized security model.

> First, our researchers collaborated with a mix of models to translate Signal’s security goals into formal mathematical specifications, with human experts reviewing every one. From there, agents powered by Gemini Carbon did the proofs, generating over six million lines of Lean, a computer language that mathematically proves the accuracy of code.

The generated Lean code here is just being checked against the "formal mathematical specifications of Signal's security goals", not checked for the low-level properties you might care about as a programmer, e.g. "will it ever leak memory" or "will it ever crash", etc. And in fact, the code is not even being checked for the reachability of non-security-violating protocol failure states, e.g. "could the protocol ever deadlock such that neither side can send messages any more".

It's still perfectly possible for the code to have all of these problems. It's now just known that, as of the commit they did this analysis against, none of those low-level problems, as far as they exist in the codebase, can cause a security-model violation.

Or, to put that another way: the system has been proven to "fail safe" in all its current failure modes, per their specific definition of safety (which is basically "keeping to the security guarantees Signal markets itself to users as having".)

Note that this is about Signal’s cryptographic protocol, not the Signal App or the surrounding platform OS.

Proofing and securing those is the way larger attack vector and work to come.

Well I’m not even sure they did that. Not really.

They took signals security goals/aim/target and used models to generate a mathematical model. Which is a bit “hey trust us bro” in 3 ways but they did have human experts fully review 1 path, partially review 1 path, and the last I’m not really sure.

The fully reviewed path was that the aims goals were turned into positive mathematical statements “we will achieve X Y Z” so if we trust the humans that part should be as strong as we achieved X Y Z.

Tons of lean code generated to prove X Y Z correct, a lot of it is entirely self consistent. But then because it’s too much to look at we had the AI judge all of it for problem areas and we had humans look at that 1% of it… okay? That’s great if your magic box can pick out the problem areas but that wasn’t proved.

My last issue is, and please tell me if I’m wrong or missed something, but what says or proves the security goals/models are necessary and sufficient? We aim to do X Y Z. Great. We aim to not do A B C. not sure if I’m quibbling or this is strictly needed but it seems missing (unless it can be captured in entirely in the positive statement) let’s assume it’s included. We did X Y and Z, we did not do A B or C. Okay what’s my prize? Unbreakable crypto?

“Um well no… we know we can have X Y and Z while not having A B and C”

And so if we have X Y Z none of A B C we know the model is good.

“Yeah, probably”

And that the code at some point in time is no better than that?

“Yeah, certainly”