softdeadlock/voron-crypto — explained in plain English
Analysis updated 2026-05-18
Review the X3DH-lite and Double Ratchet implementation for cryptographic flaws before it ships in a real messenger.
Study a working example of sender-keys group encryption and a client-side signed hash-chain membership log.
Run the included proof-of-concept exploits and fuzzing harness against the reference relay server.
Learn how an onion-routed transport hides which IP address maps to which identity key on a relay.
| softdeadlock/voron-crypto | mfori/bit-aes | nacode-studios/kdrant | |
|---|---|---|---|
| Stars | 1 | 1 | 1 |
| Language | Kotlin | Kotlin | Kotlin |
| Last pushed | — | 2020-05-11 | — |
| Maintenance | — | Dormant | — |
| Setup difficulty | moderate | moderate | moderate |
| Complexity | 5/5 | 2/5 | 3/5 |
| Audience | developer | developer | developer |
Figures from each repo's GitHub metadata at analysis time.
Unit tests run offline via Gradle, the relay-fuzzing and onion-correlation proofs of concept need local processes running.
Voron crypto is the encryption and messaging protocol core of a small end to end encrypted messenger project, published on its own to ask outside developers to review it for security problems. It does not include the phone app or deployment setup, only the underlying cryptography and protocol code. The library builds one to one private conversations using an asynchronous key agreement method similar to the Signal protocol's X3DH, followed by a Double Ratchet that keeps rotating encryption keys as messages are exchanged, so that even if a key is later exposed, past and future messages stay protected. These pieces are built on well established primitives like Curve25519, ChaCha20-Poly1305, Ed25519, and HKDF, rather than custom cryptography at that lower level. Group conversations use a simpler sender-keys scheme, the approach early WhatsApp and Signal groups used, plus a signed hash chain log that records membership and role changes on the client side, since the relay server has no built in concept of groups. There is also an optional onion style transport that sends messages through a fixed number of encrypted hops and pads them to consistent sizes, so a relay only sees one hop of a conversation and cannot easily link a connection's network address to the identity behind it. The project states plainly that this does not protect against an attacker watching both ends of a conversation at once, since that would require cover traffic that has not been built. The relay server is intentionally minimal and treated as untrusted: it forwards encrypted messages and public key material without ever seeing plaintext, and is assumed to potentially be actively hostile. A folder of prior internal security review write ups is included, along with working proof of concept exploits for bugs already found and fixed, and reviewers are asked to check that folder first before reporting something that may already be documented. The authors are upfront that no independent professional security audit has been done. All existing review is by the project's own contributors, presented as a starting point for outside review, not a certification. It is a Kotlin project built with Gradle, requiring JDK 17 or newer to run its test suite.
The encryption and protocol core of an E2EE messenger, published standalone so outside developers can review its cryptography for bugs.
Mainly Kotlin. The stack also includes Kotlin, Gradle, Curve25519.
The README does not state a license, so terms of use are unclear.
Setup difficulty is rated moderate, with roughly 30min to a first successful run.
Mainly developer.
This repo across BitVibe Labs
Verify against the repo before relying on details.