Verify, Don't Trust: Why Security Claims Must Be Checkable

Every messaging app says it is private. Every platform says it takes security seriously. The words cost nothing, and that is precisely the problem. A security claim that nobody can check is not a guarantee. It is a request for trust.

At VOIDEX we think the only honest standard is the one cryptographers have used for decades: verify, don't trust. This article explains why checkable claims matter, what makes a claim checkable, and exactly how you can check ours.

The difference between a promise and a proof

When a company says "we cannot read your messages", there are two very different things it could mean.

The first is a policy: we choose not to read them. A policy can change with new owners, new laws or a new business model. It can be broken by an insider or bypassed by an attacker who reaches the servers. It asks you to trust people you have never met.

The second is a property of the design: we are not able to read them, because we never hold the keys. A property like that does not depend on anyone's good intentions. But it only earns your confidence if you can see the design for yourself.

This is the heart of the matter. End-to-end encryption is a strong idea, but a closed system that claims it gives you no way to tell a real implementation from a weak one, or from one with a quiet exception built in.

Lessons from closed claims

History offers plenty of warnings. Products have advertised strong encryption that turned out to have weak implementations, keys stored where the company could reach them, or undisclosed ways around the protection. In several well-known cases, the truth only emerged after independent researchers took the product apart. Users who had trusted the marketing had no way of knowing sooner.

The lesson is not that every closed product is dishonest. Many are built with care. The lesson is that you cannot tell the difference from the outside, and in security, not being able to tell is itself a risk.

What makes a claim checkable

A security claim becomes checkable when outsiders can examine the pieces that matter. Four things do most of the work.

Open source cryptography

The code that performs encryption should be public, so that researchers can read it, test it and point out mistakes. Cryptographers have held this view since the nineteenth century, when Auguste Kerckhoffs argued that a system should stay secure even if everything about it except the key is known. Open source puts that principle into practice. Signal, to its great credit, has long published its code, and much of the industry's progress on secure messaging rests on that openness.

Public, specific documentation

A good security report does not say "military grade" or "bank level". It names the algorithms, the protocols, the key sizes and the limitations. Specific claims can be checked. Vague ones cannot.

Key transparency

Encryption protects a message from everyone except the holder of the key. So the most dangerous attack on a well-encrypted messenger is not breaking the maths. It is quietly giving you the wrong key, so that you encrypt your message to an attacker instead of your friend.

Key transparency closes that gap by writing every key change into a public, append-only log, built the same way as Certificate Transparency (RFC 6962), the system that keeps web certificates honest. Anyone can inspect the log, and clients can check that the key they are given is the one everyone else sees. WhatsApp announced key transparency in 2023, and it is becoming the standard for serious messengers. We explain the idea fully in key transparency.

Observable behaviour

Finally, a claim should be consistent with what anyone can observe. If a messenger says your messages are end-to-end encrypted, the data leaving your device should look like ciphertext, not readable text.

How VOIDEX makes its claims checkable

VOIDEX was designed so that its most important claims can be examined rather than taken on faith.

The cryptographic core is open source. The code that handles keys and encryption is published at github.com/voidexbycnota/voidex-crypto. It is the place to examine the protocols the security report describes: a hybrid post-quantum key agreement for direct messages that combines X25519 with ML-KEM-768, a double ratchet with post-quantum re-keying so each message has its own key, and hybrid identity signatures pairing Ed25519 with ML-DSA-65.

The security report is public and specific. The VOIDEX security report names the algorithms and protocols, including MLS (RFC 9420) for groups and private channels and DTLS-SRTP for calls, describes what VOIDEX can and cannot see, and sets out limitations plainly. It also tells you what is not end-to-end encrypted: public posts in VOIDEX Space and public channels, which are meant to be seen and are labelled that way.

Every key change goes into a public log. VOIDEX runs a key transparency log in the style of RFC 6962. Every device key change is appended to it, and its signed tree heads use Ed25519 together with ML-DSA-65. VOIDEX clients check keys against the log and refuse keys that are not in it. The log has public endpoints so anyone can audit it, and an independent witness watches it for any attempt to rewrite history.

The design keeps VOIDEX out of the loop. Keys are created on members' devices. VOIDEX's servers store only public keys and ciphertext. Each member's recovery code, which opens their message history on a new device, is never held by VOIDEX. That is a property of the design, not a policy.

How to check VOIDEX yourself

You do not need to be a cryptographer to start verifying. Here is a practical path, from simplest to most technical.

1. Read the security report. Start at voidex.com/security. Check that it names specific, standard algorithms rather than marketing terms, and note what it says VOIDEX can and cannot read.
2. Read the code. Visit the voidex-crypto repository. Even without deep expertise, you can see which standards are used and how the pieces fit. If you know someone with a background in applied cryptography, ask them to look.
3. Watch the traffic. Open VOIDEX in a desktop browser, open the browser's developer tools and select the network panel. Send a direct message and inspect the request that carries it. You should see an encrypted payload, not the words you typed.
4. Audit the key transparency log. The security report points to the log's public endpoints. A technical reader can fetch the signed tree head, request proofs, and confirm that the log only ever grows, exactly as RFC 6962 intends.
5. Compare with what VOIDEX says it cannot do. A trustworthy system is as clear about its limits as its strengths. Check that the report's stated limits match what you observe.

Each of these steps builds confidence that does not depend on believing us.

Honesty about limits

Verification is a practice, not a single event. Code evolves, and every release is a new thing to check. Some parts of any real system, such as how a server is operated day to day, cannot be fully observed from outside, which is why the design matters so much: a server that never holds your keys has far less to hide. Open code also does not guarantee correctness on its own. It guarantees that mistakes can be found, which is the best anyone can honestly offer.

We would rather tell you precisely what VOIDEX does and let you test it than ask you to accept a slogan. That is also why we never describe VOIDEX as "unbreakable" or "unhackable". No honest security team uses those words.

Why this matters more for a private network

VOIDEX is invite-only, owned by CNOTA, and free with no ads, no third-party trackers and no selling of data. For a platform with no advertising business, there is no reason to hide how it works, and every reason to show it. The people VOIDEX is built for, including founders, families and public figures, are exactly the people who should demand evidence rather than reassurance. We wrote about that audience in private communication for executives.

Trust in security should be earned the way it is in science: by publishing the method and inviting others to check the result.

VOIDEX is invite-only. Request access, or start verifying today with the VOIDEX security report.

Sources

• VOIDEX cryptographic core (open source): https://github.com/voidexbycnota/voidex-crypto
• VOIDEX security report: https://voidex.com/security
• IETF, RFC 6962, Certificate Transparency: https://www.rfc-editor.org/rfc/rfc6962
• IETF, RFC 9420, The Messaging Layer Security Protocol: https://www.rfc-editor.org/rfc/rfc9420
• NIST, Post-Quantum Cryptography Standardization: https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization