Service eligibility and regional restrictions
PuppyIP serves only compliant overseas businesses and their authorized personnel. Proxy services are not available in mainland China. The service may only be used for lawful business activities outside mainland China. Use of this service within mainland China is prohibited.
Hosting a proxy IP or server overseas does not change these restrictions. The service must not be provided to end users in mainland China through relaying, forwarding, sharing or resale. Before use, read the Terms of Service.
Key Takeaways
- The target is one-to-one session code from libsignal v0.105.4 and SPQR v1.6.0, in a compiled AArch64 Linux command-line program; the theorems do not cover key generation.
- Human researchers review and approve formal specifications, AI prover agents produce proofs, and Lean’s kernel checks each proof against the approved specification.
- The paper reports symbolic and computational results separately because their attacker capabilities, cryptographic assumptions, and exclusions differ.
- These results are not an unconditional guarantee for every official Signal app, device, version, or quantum attacker. The model, environment, and trusted base matter.
Start with the exact target
The paper studies one-to-one PQXDH session setup and Triple Ratchet messaging in libsignal-protocol v0.105.4 with SPQR v1.6.0. The researchers wrap the unmodified Rust code in a small command-line program, libsignal-cli, and compile it into an AArch64 Linux executable. The theorems concern runs of that machine-code program.
The theorems cover session initialization, sending, and receiving; key generation is explicitly outside their scope. This target is not Signal’s iOS or Android app, nor every operating system, device, multi-party session, or future release. “Machine-code level” means the proof reaches a particular executable; it does not turn the result into certification of the whole product.
People approve the specification; Lean checks the proof
AlphaProof Code separates human-guided specification work from automated proving. Researchers and a specification agent express protocol models and desired properties in Lean. Reviewers critique the specification, a human approves it, and prover agents then try to show that the program satisfies it. Lean’s kernel checks an accepted proof against that approved specification.
The precise conclusion is that the program satisfies properties expressed by those specifications and models. The system does not decide by itself what “secure” should mean, and it does not establish that the specifications cover every product behavior. Their scope and correctness, how the model corresponds to the program, and the theorem’s premises remain central to interpreting the result.
Read each security property with its conditions
The paper addresses forward secrecy, authentication, handshake secrecy, and post-compromise security for message keys. In plain terms, forward secrecy asks whether a later key compromise can expose earlier protected messages; post-compromise security asks whether, under particular conditions, a protocol can regain protection for later messages after a temporary compromise. These are properties within a model, not promises about every real-world compromise scenario.
The reported properties also analyze PQXDH together with the Triple Ratchet under different formal models. “Post-quantum” is not a complete conclusion on its own: a reader must identify which proof is being discussed, what attackers it permits, and which cryptographic primitives and environmental assumptions it uses.
The symbolic and computational models are different claims
The symbolic model idealizes cryptographic primitives and describes attackers through symbolic operations. The reported theorems include forward secrecy and post-compromise security for message keys, handshake authentication, and handshake secrecy. One scenario allows a later break of Diffie–Hellman (DH) to represent a limited quantum-attacker setting. The model does not prove computational secrecy, cover protocols with more than two parties, or establish SPQR’s post-quantum healing property.
The computational model gives a concrete security bound against bounded classical attackers for confidentiality and authenticity, with forward secrecy and post-compromise security for PQXDH composed with the Triple Ratchet. It makes no guarantee against quantum attackers. The paper also excludes multi-device state and adversarial first messages later promoted to sessions, among other restrictions, and notes that the bound can become vacuous at large scale. The symbolic model’s DH-break scenario cannot be transferred into a quantum guarantee for the computational result.
The proof still has a trusted base
The paper’s trusted base includes Lean’s kernel, AArch64 and Linux process semantics, contracts for some hooked routines, cryptographic assumptions, and tools used to build the binary and extract symbols. The authors do not list the Rust compiler as trusted. That does not mean every compiler output automatically inherits the proof: the result concerns the executable that corresponds to the specifications and machine-code model.
The model also simplifies the environment. Fixed-length messages, no multi-device state, and identity keys trusted on first use all limit the claim; the paper says some environment assumptions are argued informally. A security review should look beyond “Lean checked it” to the specifications, model, external contracts, and execution environment used by the theorem.
Use four questions to assess a security claim
First identify the build, version, and platform being verified. Then find the exact property in the theorem. Next separate the symbolic and computational models and check each model’s attacker, cryptographic assumptions, and exclusions. Finally, identify which definitions, semantics, contracts, and build tools outside Lean’s proof still need to be trusted.
Read this way, the result is precise: researchers machine-checked several protocol security properties for one libsignal command-line build under stated models and premises. It is a significant formal-verification result, but it does not establish that every Signal app and deployment has been proved secure, or that the result transfers automatically to a new build or another system.
Sources
Frequently Asked Questions
If the Rust compiler is not in the trusted base, are other Rust builds covered automatically?
No. The theorems target an AArch64 executable corresponding to the Lean machine-code semantics and proof. The compiler need not be trusted to prove properties of that particular program, but changing the source, dependencies, compiler options, or build output does not inherit the result merely because the project is still written in Rust. Check that the new target has matching proof evidence.
Do Signal users need to enable AlphaProof Code or change a client setting?
The two sources describe a research verification effort; they do not describe a new Signal-user feature, client setting, or upgrade procedure. Treat this as a result about a particular libsignal build, not a product feature that users need to activate.