GitHub
Wiki
SimpleX Group
Soundtrack
EN DE
Cover-- / ----
--
--
0:00
--:--
Lyrics
Select a track...
Close
SimpleGo encryption architecture with 4 independent encryption layers per message. Hardware encryption vs software encryption comparison. Double Ratchet end-to-end encryption with X3DH key agreement over Curve448. Post-quantum cryptography sntrup761 hybrid key exchange on embedded hardware. NaCl cryptobox X25519 XSalsa20 Poly1305 per-queue encryption. Onion routing via Private Message Routing. TLS 1.3 transport with ALPN smp/1 and certificate fingerprint pinning. AES-256-GCM storage encryption with HKDF-SHA256 per-contact key derivation. Encrypted messenger comparison: SimpleGo vs Signal vs Telegram vs WhatsApp vs Threema vs Matrix vs Session vs Briar. Most secure messenger protocol 2026. How many encryption layers does Signal use. What is the most encrypted messaging app. End-to-end encryption hardware device. Post-quantum encrypted phone. Quantum-resistant messenger. Hardware security module for messaging. SimpleX Protocol encryption explained. Perfect forward secrecy hardware device. Zero-knowledge relay server encryption. Metadata protection encrypted communication.

Four Layers of Encryption.
Per Message. Every Time.

SimpleGo implements the complete SimpleX cryptographic stack natively in C on bare-metal microcontrollers. Four nested cryptographic envelopes per message, routed through TLS 1.3 transport via two relay servers. All content padded to fixed 16 KB blocks.

Why Four Layers Matter

Most messaging protocols use two encryption layers: end-to-end encryption plus TLS transport. SimpleGo wraps every message in four nested cryptographic envelopes and routes them through three separate TLS 1.3 tunnels via two relay servers. Each layer defends against a different threat.

4 Application Layers - Per Message
e2e
Layer 1 - Double Ratchet End-to-End
The innermost envelope. Initial key agreement uses X3DH (Extended Triple Diffie-Hellman) over Curve448 to establish a shared secret without any server involvement. The Double Ratchet Algorithm then derives a unique encryption key for every single message. Two ratchets run simultaneously: a symmetric-key ratchet using HKDF-SHA256 that advances with every message, and a DH ratchet that rotates the root key with every exchange. The key for message #42 has zero mathematical relationship to message #43.
Key agreement is augmented with hybrid post-quantum cryptography: sntrup761 KEM integrated into the X448 Double Ratchet on SimpleGo hardware. Both classical and post-quantum algorithms protect every session. If a quantum computer breaks one, the other still holds.
X3DH + X448Double RatchetAES-256-GCMHKDF-SHA256Perfect Forward SecrecyPost-Compromise Securitysntrup761 PQ-KEM
Defends against: Server compromise, network surveillance, MITM, future quantum computers. Even if every relay server is fully controlled by an adversary, message content remains encrypted with keys that only exist on sender and recipient devices.
▼ wrapped in ▼
s2d
Layer 2 - Sender-to-Destination NaCl Cryptobox
The already-encrypted message gets a second envelope addressed to the recipient's destination relay server. This uses X25519 key exchange with XSalsa20-Poly1305 encryption, with a unique keypair per message queue. The forwarding relay sees only an opaque blob destined for the next hop. Even if TLS is broken, queue correlation between different contacts is impossible.
X25519 + XSalsa20-Poly1305Per-Queue Unique KeysNaCl Cryptobox
Defends against: Forwarding relay seeing message metadata. Knowledge of Queue A gives zero information about Queue B.
▼ wrapped in ▼
d2r
Layer 3 - Destination-to-Recipient NaCl Cryptobox
The destination relay server re-encrypts the message with the recipient's public key before delivery. This prevents correlation between incoming and outgoing traffic at the relay, even if an adversary has full access to the server's network interface. Incoming and outgoing packets are cryptographically unlinkable.
NaCl Cryptobox re-encryptionTraffic decorrelation
Defends against: Traffic analysis at the destination relay. An observer cannot match incoming sends to outgoing deliveries.
▼ wrapped in ▼
f2d
Layer 4 - Forwarding-to-Destination Onion Routing
Private Message Routing (since SimpleX v5.8) adds 2-hop onion routing between relay servers. The sender's relay forwards the message to the recipient's relay without knowing the final destination. The recipient's relay delivers without knowing the original sender. Neither relay sees the complete communication path.
2-Hop Onion RoutingPFWD / RFWD CommandsPrivate Message Routing
Defends against: Both relay servers colluding. Even joint analysis of all relay logs cannot reconstruct sender-recipient pairs.
3 Transport Tunnels
L5 TLS 1.3
Sender to Forwarding Relay
L6 TLS 1.3
Forwarding to Destination Relay
L7 TLS 1.3
Destination Relay to Recipient
All content padded to 16,384 bytes at every layer. A one-word reply looks identical to a 15,000-character message on the wire.

Quantum-Resistant Key Exchange

Every key agreement in the SimpleGo ecosystem is protected against both classical and quantum-level computation. The approach uses hybrid cryptography: a classical algorithm and a post-quantum algorithm combined so that breaking either alone is insufficient.

SimpleGo Hardware
sntrup761 + X448

Streamlined NTRU Prime 761 KEM integrated directly into the X448 Double Ratchet. Every key agreement during the ratchet advance includes a post-quantum component. Implemented natively in C on the ESP32-S3.

sntrup761X448 (Curve448)Lattice-based KEM
Active - implemented in firmware
GoRelay Server
ML-KEM-768 + X25519

The GoRelay Protocol (GRP) uses ML-KEM-768 (FIPS 203, formerly CRYSTALS-Kyber) hybridized with X25519 for transport encryption via the Noise Protocol Framework. Mandatory on every GRP connection - no fallback to classical-only.

ML-KEM-768X25519Noise IK/XX
Planned - GRP Phase 4

Why two PQ algorithms? SimpleGo uses sntrup761 (NTRU lattice family) for the Double Ratchet E2E layer. GoRelay uses ML-KEM-768 (MLWE lattice family, NIST standardized) for transport. Different mathematical foundations ensure that a breakthrough against one family does not compromise the other. The ecosystem is resilient against advances in both classical and quantum cryptanalysis.

The Protocol With No User Identifiers

The SimpleX Protocol uses no persistent user identity of any kind: no phone numbers, no usernames, no public keys as identifiers. Communication happens through ephemeral unidirectional message queues. No party, including relay servers, can correlate senders and recipients.

Unidirectional Message Queues
Each conversation uses a pair of one-way message queues on different servers. No single server knows both sides of a conversation.
No Contact Graph
Even with full access to all relay servers, no adversary can construct a social graph. Other protocols protect content but leak metadata about who communicates with whom.
Ephemeral by Design
SimpleGo devices have no phone number, no IMEI, no account. Cryptographic identities are ephemeral and exist only for the duration of a conversation. A factory reset produces a cryptographically unrelated device.

Protocol Comparison

ProtocolUser IdentifierEnc. LayersE2E DefaultContact Graph VisibleForward SecrecyPost-Quantum
SMS / RCSPhone number + IMSI0 (plaintext)NoYesNoNo
TelegramPhone number1 (E2E optional)NoYesNoNo
iMessageApple ID2YesYesPartialYes (PQ3)
WhatsAppPhone number2YesYesYesNo
SignalPhone number2YesPartialYesYes (PQXDH)
ThreemaRandom ID2YesYesPartialNo
MatrixUsername@server2YesYesPartialNo
SessionSession ID (pubkey)2YesReducedNoNo
BriarPublic key (Tor)2YesReducedYesNo
SimpleX / SimpleGoNone4 + 3 TLSYesNoYesYes

SimpleGo + GoRelay: From Silicon to Server

The SimpleGo ecosystem controls the entire communication path. SimpleGo is the hardware client. GoRelay is the relay server. Both are open source, both are under one codebase's control.

Hardware Client
SimpleGo

Native C on ESP32-S3. 47 source files, 21,863 lines. FreeRTOS, mbedTLS, libsodium. Four encryption layers per message. sntrup761 post-quantum. AES-256-GCM encrypted SD storage.

SMP v7 | AGPL-3.0
Relay Server
GoRelay

Go single binary. Zero-knowledge by construction. Per-message AES-256-GCM storage encryption with cryptographic deletion. SMP v7 compatible. GRP protocol planned with Noise + ML-KEM-768.

SMP v7 + GRP/1 (planned) | AGPL-3.0
Server-Side Security Properties
Zero-knowledge: The code to read message content does not exist. No admin backdoor, no debug mode.
Per-message encryption: Every message in the database has its own random AES-256-GCM key.
Cryptographic deletion: When a message is acknowledged, the encryption key is zeroed before the database entry is removed.
Constant-time auth: Signature verification always runs, even for non-existent queues. Timing attacks reveal nothing.
No IP logging: Structurally absent from the codebase, not disabled by configuration.
Fixed 16 KB blocks: Traffic analysis cannot determine message size or command type.

Native C on Bare Metal

Every cryptographic primitive runs natively in C. No interpreters, no virtual machines, no garbage collectors between your keys and the hardware.

Key Agreement
X3DH + X448
wolfSSL (wolfCrypt) for X448 Diffie-Hellman. Byte-order reversal for Haskell cryptonite compatibility verified byte-by-byte against the reference implementation.
Double Ratchet
Custom C Implementation
HKDF-SHA256 for key derivation. AES-256-GCM for message encryption. Ratchet state persisted to NVS flash, survives reboot. 128 simultaneous ratchet states in PSRAM.
Per-Queue Encryption
libsodium NaCl
X25519 + XSalsa20 + Poly1305. Non-standard HSalsa20 construction reverse-engineered from the Haskell implementation for protocol compatibility.
Post-Quantum
sntrup761
Streamlined NTRU Prime KEM integrated into the X448 Double Ratchet. Lattice-based cryptosystem providing protection against quantum-level computation.
TLS Transport
mbedTLS (with SimpleX patch)
TLS 1.3 with ALPN smp/1. Five undocumented patches for Ed25519/Ed448 certificate compatibility. Server fingerprint pinning via SHA256 of CA cert DER.
Storage Encryption
AES-256-GCM + HKDF
Chat history on MicroSD encrypted with per-contact keys derived via HKDF-SHA256. Hardware-accelerated AES on the ESP32-S3. Plaintext never leaves the decrypt call.

Audited. Verified. Open.

Trail of Bits
July 2024

The SimpleX SMP protocol underwent a comprehensive cryptographic design review by Trail of Bits. The review assessed the protocol's security properties and formally verified the queue negotiation protocol. SimpleGo implements this exact protocol specification.

SimpleGo's own codebase is fully open source under AGPL-3.0. Every line of cryptographic code is publicly auditable on GitHub. An independent security audit of the C implementation is planned once the protocol stack is feature-complete.

All source code, protocol documentation, and hardware schematics are published under open-source licenses. Security claims that cannot be independently verified are marketing, not engineering.

Encryption Only Matters When the Hardware Is Trustworthy

The strongest cryptographic architecture in the world is only as secure as the platform it runs on. SimpleGo combines both.

Cover fullscreen