An offline test should yield a specific result; a hash or cryptographic demonstration is not a full product audit.
Offline testing can show that a specific calculation runs without a live server response. That is valuable, but it does not prove the security of an entire messenger. For a useful result, record exactly which file, version, input and output you tested.
File hashes, release signatures, test vectors, reproducible builds and security audits answer different questions. Combining evidence is more useful than turning any one of them into a “complete security seal”.
What does each kind of evidence show?
| Evidence | A limited, valid conclusion | What it does not automatically prove |
|---|---|---|
| File SHA-256 | The file matches the reference digest | The reference source is honest or the code is flawless |
| APK signature | The signature is valid for the package and is associated with the signing key | That key belongs to your intended publisher, unless checked separately |
| Test vectors | Covered cases produce the expected output | All product states and errors are covered |
| Reproducible build | Specified source and environment produce identical output | The source code has no vulnerabilities |
| Audit | A particular scope and version have been examined | Later changes and out-of-scope components have also been approved |
The definition of reproducible builds relies on specified inputs and environment. The official Android apksigner tool checks APK signatures; this is not the same as calculating a hash.
What does Livara’s Proof Lab currently cover?
The Proof Lab page introduces a local APK hashing tool and demonstrations of P-256, HKDF and AES-GCM operations, including changing one bit to observe an authenticity-check failure. The page explicitly says that the complete LVR1/LGS1 combination is outside this test bench’s scope.
Write the correct conclusion as follows: “This file matched the reference digest” or “This cryptographic demonstration rejected the tampering tested.” Do not say “The entire hybrid protocol and the complete installed version were independently audited.” This article does not report a new hands-on test of that tool.
How do you prepare a repeatable offline test?
- Define the objective. Do you want to check a file’s identity or the behavior of a cryptographic operation?
- Record the version and source. The APK name, version number, download address and digest for that release must correspond to one another.
- Prepare the tool and input from a trusted source. Going offline does not make code that was malicious from the outset trustworthy.
- Use nonsensitive test data. A cryptographic demonstration does not require private messages or real secrets.
- Disconnect and repeat the test. This step assesses dependence on a live response, not trust in code downloaded earlier.
- Record results and errors. Do not replace version differences, loading failures or mismatched output with “pass”.
If the hash differs, stop installation and first check the version, file and reference source. A mismatch may result from choosing a different release; do not declare it definitely malware or definitely harmless without investigating.
How do test vectors differ from official certification?
A test vector specifies the input and expected output of a behavior. Collections such as Wycheproof help test libraries against cases associated with known attacks. Passing them does not establish coverage of unknown cases.
NIST CAVP has an algorithm-validation process. Running a few public vectors in a browser is not the same as obtaining a validation certificate; using a standard algorithm does not automatically certify a product either.
What should we ask for when comparing messengers?
Ask the same questions for Livara, Signal, WhatsApp, Session or Element: what is the exact version? Which file is official? How is the signing key or reference digest verified? Which tests can be run? Which code and components were included in the audit report?
This article is not a tested ranking of these products. The absence of a single-page tool is not proof of an absence of security evidence; its presence does not prove the superiority of the whole product either. Compare the official documentation for that version and a repeatable report.
A useful results sheet
In a short report, record the objective, version, file source, hash, tool and its version, network state, nonsensitive input, expected output, observed output and limitations. If another test has not been performed, mark it “untested”.
Verifying a contact’s key is also a separate check. A local tool can demonstrate an operation, but it does not verify the other party’s identity or the health of their phone for you. Read Livara’s security boundaries alongside the results rather than treating a perfect score in a tool as a guarantee covering every boundary.
