Most messaging protocols use two encryption layers: end-to-end encryption plus TLS transport. SimpleX wraps every message in four nested cryptographic envelopes and routes it through TLS 1.3 transport via two relay servers. Each layer defends against a different attacker with a different capability.
The innermost envelope. X3DH key agreement, then the Double Ratchet derives unique keys for every single message. Even if one key is compromised, all other messages remain secure. Since v5.6, augmented with hybrid post-quantum crypto (CRYSTALS-Kyber + Streamlined NTRU Prime).
The already-encrypted message gets a second envelope addressed to the recipient's destination relay. This hides the message metadata (queue address, notification flags) from the forwarding relay. Even if TLS is broken, queue correlation is impossible.
The destination server re-encrypts the message with a recipient-specific key before delivery. Incoming and outgoing ciphertext is completely different — a network observer cannot correlate what goes in with what comes out.
The outermost application envelope. Before reaching the destination, the message routes through a forwarding relay chosen by the sender — a 2-hop onion routing protocol inspired by Tor. This layer ensures no repeated identifiers or ciphertext between the two relay hops, preventing traffic correlation even if TLS is compromised on both hops simultaneously.
Every message padded to fixed block sizes at each layer. A one-word reply is indistinguishable from a 10,000-character essay.
4 encryption layers · TLS 1.3 transport · 2 relay servers · neither relay knows both sender and recipient · no other messaging system does this.
Quantum computers will eventually break the elliptic curve cryptography that protects today's communications. SimpleGo is built to survive that transition — not as an afterthought, but as a core architectural requirement.
A sufficiently capable quantum computer running Shor's algorithm would break RSA, Diffie-Hellman, and elliptic curve cryptography in hours. While such machines don't yet exist, intelligence agencies are already executing "harvest now, decrypt later" campaigns — recording encrypted traffic today to decrypt it once quantum computers become available.
This is not a theoretical concern. NIST spent eight years evaluating 82 candidate algorithms before finalizing FIPS 203 (ML-KEM) in August 2024 as the primary post-quantum key encapsulation standard. The algorithm, derived from CRYSTALS-Kyber, is designed to resist attacks from both classical and quantum computers.
SimpleX Protocol already implements hybrid post-quantum key exchange since version 5.6, combining CRYSTALS-Kyber with Streamlined NTRU Prime — two mathematically independent post-quantum algorithms from different design families. If either algorithm is broken, the other still provides security.
A peer-reviewed implementation of CRYSTALS-Kyber on ESP32 (Segatz & Hammer, KTH Stockholm, 2025) demonstrates that post-quantum cryptography is fully viable on SimpleGo's hardware platform.
By leveraging the ESP32-S3's dual-core architecture and hardware SHA/AES accelerators, the researchers achieved significant performance improvements over naive implementations — proving that a 240 MHz microcontroller can perform post-quantum key exchange in real time.
SimpleX is the only messaging protocol that uses no persistent user identity of any kind — no phone numbers, no usernames, no public keys as identifiers. This isn't a feature. It's the fundamental architecture.
Communication doesn't happen through "accounts" or "contacts." Each conversation uses a pair of one-way message queues. The sender's queue and the recipient's queue are on different servers, operated by different parties. No single server knows both sides of a conversation.
Even with full access to all relay servers, no adversary can construct a social graph — the map of who communicates with whom. Other protocols protect message content but leak this metadata. As former NSA General Counsel Stewart Baker stated: metadata tells you everything about somebody's life.
A SimpleGo device has no phone number, no IMEI, no Apple or Google account. It generates ephemeral cryptographic identities that exist only for the duration of a conversation. Power off the device, destroy it, buy another — your communication pattern leaves no persistent trace.
| Protocol / App | User Identifier | Encryption Layers | E2E Default? | Contact Graph Visible? | Forward Secrecy | Post-Quantum |
|---|---|---|---|---|---|---|
| SMS / RCS | Phone number + IMSI | 0 (plaintext) | No | Yes — carrier + authorities | No | No |
| Telegram | Phone number | 1 (MTProto 2.0) — E2E optional | No — server-side default | Yes — Telegram servers | No (server chats) | No |
| iMessage | Apple ID + phone number | 2 (custom + TLS) | Yes | Yes — Apple servers | Partial | Yes (PQ3, since iOS 17.4) |
| Phone number | 2 (Signal Protocol + Noise Pipes) | Yes | Yes — Meta servers | Yes | No | |
| Signal | Phone number | 2 (Double Ratchet + TLS) | Yes | Partially — Signal servers via SGX | Yes | Yes (PQXDH, since Sept 2023) |
| Threema | Threema ID (random) | 2 (NaCl + TLS) | Yes | Yes — Threema servers | Partial (Ibex) | No |
| Wire | Email or phone | 2 (Proteus/MLS + TLS) | Yes | Yes — Wire servers | Yes | No |
| Matrix / Element | Username@server | 2 (Vodozemac/Megolm + TLS) | Yes (rooms) | Yes — homeserver | Partial (Megolm) | No |
| Session | Session ID (public key) | 2 (custom + onion routing) | Yes | Reduced — onion routed | No (no ratchet) | No |
| Briar | Public key (Tor) | 2 (Bramble + Tor/direct) | Yes | Reduced — P2P via Tor | Yes | No |
| SimpleX / SimpleGo | None — zero identifiers | 4 (2 E2E + 2-3 transport) | Yes | No — to nobody | Yes | Yes (Kyber + NTRU) |
Signal pioneered post-quantum protection with PQXDH in September 2023. Apple followed with PQ3 in iMessage. SimpleX uses a hybrid approach combining CRYSTALS-Kyber and Streamlined NTRU Prime since v5.6 — the only protocol with dual post-quantum algorithms. All other major messengers remain vulnerable to harvest-now-decrypt-later quantum attacks.
SimpleGo is the world's first implementation of the SimpleX Messaging Protocol outside of the original Haskell codebase. Every cryptographic primitive runs natively in C — no interpreters, no virtual machines, no garbage collectors between your keys and the hardware.
Extended Triple Diffie-Hellman establishes shared secrets between contacts. Curve25519 provides 128-bit security equivalent. mbedTLS hardware-accelerated where available.
Symmetric-key ratchet combined with Diffie-Hellman ratchet. New keys derived for every message. HKDF-SHA256 for key derivation. Persistent ratchet state stored in NVS flash with encryption.
NaCl cryptobox for per-queue and server encryption layers. 256-bit keys, 192-bit nonces, Poly1305 authentication. SimpleX uses a non-standard nonce construction that SimpleGo matches exactly.
Full TLS 1.3 handshake with SMP relay servers. Certificate pinning on first contact. mbedTLS provides hardware acceleration on ESP32-S3 for AES and SHA operations.
Ratchet state persisted after every encrypt/decrypt operation. NVS flash encryption with AES-256-XTS via eFuse keys. Hardware secure elements (Tier 2/3) provide tamper-resistant root-of-trust.
TLS and cryptographic operations in 512KB internal SRAM (DMA-compatible). Contact data and ratchet state arrays in 8MB PSRAM. 128 concurrent contacts supported with zero-latency switching.
The four per-message encryption layers protect data in transit. But what about data at rest on the device? SimpleGo implements multiple independent hardware security domains that protect keys, chat history, and device integrity even if the device is physically seized.
4 per-message encryption layers + TLS 1.3 transport
eFuse-derived AES-256-XTS encryption on internal flash memory
AES-256 encrypted chat history on removable SD card
Hardware secure elements + tamper detection + secure boot chain
Dual-core Xtensa LX7 at 240 MHz with 512KB internal SRAM and 8MB PSRAM. In Model 1, this is the main processor running the complete SimpleX protocol stack. In Models 2 and 3, the ESP32-C6 serves as a dedicated WiFi module while the STM32 handles all cryptographic operations.
Even in Model 1 — the €100-200 maker edition — every ratchet state, every contact key, every piece of persistent data is encrypted at the hardware level with a key that cannot be extracted from the chip. Desoldering the flash memory gives an attacker nothing but encrypted bytes.
The eFuse mechanism is physically destructive: writing a bit literally blows a microscopic fuse inside the silicon. There is no "unburning" an eFuse. This is not software protection that can be bypassed with a debugger — it is a permanent physical change to the chip.
Espressif's high-performance RISC-V processor: dual-core at 400 MHz (HP core) plus a low-power core at 40 MHz, with 768KB internal SRAM. The P4 has no integrated WiFi or Bluetooth — it requires an ESP32-C6 companion chip as a dedicated radio, creating the same hardware-enforced crypto/radio separation as the STM32-based models while staying entirely within the Espressif ecosystem and ESP-IDF toolchain.
The ESP32-P4 bridges the gap between Model 1 and Model 2. It gives you the crypto/radio hardware separation of the STM32 architecture without leaving the Espressif ecosystem. Same ESP-IDF toolchain, same C codebase, same development workflow — but with the architectural security upgrade that matters most: the radio chip never sees your keys.
At 400 MHz with 768KB SRAM, the P4 also has headroom for post-quantum cryptography operations that push the S3 to its limits. ML-KEM key encapsulation and Double Ratchet with PQC augmentation run noticeably faster.
ARM Cortex-M33 at 160 MHz with TrustZone hardware isolation. In Model 2, this processor handles all cryptographic operations and protocol logic while the ESP32-C6 is reduced to a pure WiFi radio. The STM32U5 series was specifically designed by ST for security-critical applications — IoT, payment terminals, and industrial control.
This is the same architectural principle that makes the Purism Librem 5 noteworthy: separating the radio from the crypto engine. But where the Librem 5 uses a Linux-based application processor, SimpleGo uses bare-metal firmware with TrustZone — a fundamentally smaller and more auditable attack surface.
The same ARM Cortex-M33 core as the U585, but with 2.5MB Flash, 2.5MB SRAM, and a GPU-capable LTDC display controller for driving premium AMOLED screens. Every security feature of the U585 is present, plus additional capabilities that enable the full "Vault" experience.
The Model 3 uses the same STM32 + ESP32-C6 architecture split as Model 2, but adds the triple-vendor secure element array and active tamper detection with battery-backed RTC tamper monitoring — the device detects intrusion attempts even when powered off.
Secure key storage, ECDH key agreement, ECDSA signing, hardware RNG. 16 key slots with individual access policies. The industry standard for IoT secure elements.
Advanced shielding against physical side-channel attacks, fault injection protection, and secure monotonic counters. German engineering from the world's largest secure element manufacturer.
IoT-optimized secure element with native NIST P-256/384, Ed25519, AES, and RSA-4096 support. Pre-provisioned root of trust. Active shield mesh against probing attacks.
Why three vendors? In 2024, NinjaLab researchers demonstrated the "Eucleak" attack — a side-channel vulnerability in Infineon SLE78 secure elements used in YubiKeys, passports, and crypto wallets worldwide. The flaw existed for 14 years in a CC EAL5+-certified chip. A single-vendor SE strategy means a single point of failure. Triple-vendor means: if one manufacturer's silicon has an undiscovered vulnerability, the other two still protect your keys.
No device in any category — consumer, military, or prototype — was found to use secure elements from three different manufacturers. The closest is the Keystone 3 Pro hardware wallet with three SE chips from two vendors. Triple-vendor secure elements appear to be an entirely novel concept in hardware security design.
All chat messages stored on the removable microSD card are encrypted with AES-256 before writing. The encryption key is derived from keys stored in the secure element (Model 2/3) or eFuse-protected NVS (Model 1). Removing the SD card and reading it on another device yields only encrypted data.
The SD card is the only component that stores message history. Internal flash stores only ratchet states and contact keys — never message content. This separation means: destroy the SD card and all message history is gone. The device can continue operating with existing contacts but no chat history.
Different key material protects different domains. The SD card encryption key, the NVS flash encryption key, and the per-contact ratchet keys are all independent. Compromising one domain does not give access to any other. This is the same principle used in military Red/Black hardware separation — but applied at the key management level.
Panic button triggers secure erase of all keys and ratchet states from NVS. Flash encryption via eFuse protects data at rest. No hardware tamper sensors — security relies on the eFuse-protected flash encryption and the physical security of the 3D-printed or user-built enclosure.
STM32U585 tamper detection pins connected to case intrusion switches. Opening the CNC-machined aluminum enclosure triggers an interrupt that wipes all key material from RAM and NVS before an attacker can probe the circuit board. RDP Level 2 permanently disables debug access.
Everything from Model 2, plus battery-backed RTC tamper monitoring — detects intrusion even when the device is powered off. Multiple tamper zones (case, PCB, display). Triple SE array ensures key material is distributed: even extracting one chip leaves the key reconstruction incomplete.
| Security Feature | Model 1 — Maker | Model 1 Pro | Model 2 — Shield | Model 3 — Vault |
|---|---|---|---|---|
| Main Processor | ESP32-S3 | ESP32-P4 | STM32U585 | STM32U5A9 |
| Architecture | Xtensa LX7 240 MHz | RISC-V 400 MHz | Cortex-M33 160 MHz | Cortex-M33 160 MHz |
| Internal SRAM | 512 KB | 768 KB | 786 KB | 2.5 MB |
| WiFi Module | Integrated | ESP32-C6 (radio only) | ESP32-C6 (radio only) | ESP32-C6 (radio only) |
| Crypto/Radio Separation | ✗ | ✓ Hardware | ✓ Hardware | ✓ Hardware |
| ARM TrustZone | ✗ | ✗ (RISC-V) | ✓ | ✓ |
| Flash Encryption | AES-256-XTS (eFuse) | AES-256-XTS (eFuse) | AES-256-XTS + OTFDEC | AES-256-XTS + OTFDEC |
| Secure Boot | RSA-3072 / ECDSA | RSA-3072 / ECDSA | STM32 Secure Boot | STM32 Secure Boot |
| Debug Protection | eFuse JTAG disable | eFuse JTAG disable | RDP Level 2 (permanent) | RDP Level 2 (permanent) |
| Hardware TRNG | ✓ | ✓ | ✓ | ✓ |
| AES/SHA Accelerator | ✓ | ✓ + RSA/ECC | ✓ + PKA | ✓ + PKA |
| Display Interface | SPI (2.8" TFT) | MIPI-DSI | SPI / Parallel | LTDC (AMOLED) |
| Secure Elements | None | Optional 1 SE | 1-2 SE | 3 SE (3 vendors) |
| Tamper Detection | Software wipe | Software wipe | Hardware pins | Active + battery-backed |
| SD Card Encryption | AES-256 | AES-256 | AES-256 (SE-derived key) | AES-256 (SE-derived key) |
| Enclosure | 3D-printed / DIY | 3D-printed / DIY | CNC aluminum | CNC aluminum + laser engraving |
| Price Range | €100 — €500 | €500 — €1,500 | €1,500 — €15,000 | €1,000+ |
All four models implement the same SimpleX Protocol with the same four per-message encryption layers. The difference is in how the device protects the keys that make that encryption work. Model 1 relies on ESP32-S3's built-in security (eFuse, flash encryption, secure boot). Model 1 Pro upgrades to the ESP32-P4, adding hardware crypto/radio separation while staying in the Espressif ecosystem. Model 2 adds ARM TrustZone, STM32 tamper pins, and external secure elements. Model 3 adds triple-vendor SE redundancy and active tamper detection that works even when powered off.
After researching more than 70 devices across consumer, military, criminal, and DIY domains, we found that no existing device — or even published concept — combines more than three of SimpleGo's six security properties.
| Device / Category | Type | 4× Enc. | Bare Metal | No Baseband | No Identity | Multi-Vendor SE | Open Source | Score |
|---|---|---|---|---|---|---|---|---|
| SimpleGo (Tier 3) | Dedicated HW | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | 6/6 |
| Open-Source Mesh Devices | ||||||||
| Meshtastic (T-Deck) | LoRa Mesh | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | 3/6 |
| MeshCore | LoRa Mesh | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | 3/6 |
| Reticulum / RNode | LoRa Stack | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | 3/6 |
| Armachat | LoRa Mesh | ✗ | ✓ | ✓ | ✗ | ✗ | ✓ | 3/6 |
| Hardened Smartphones | ||||||||
| Bittium Tough Mobile 2C | Finland, ~€2,000 | ~ | ✗ | ✗ | ✗ | ✗ | ✗ | 0.5/6 |
| GrapheneOS / Pixel | $499–$1,799 | ✗ | ✗ | ✗ | ✗ | ✗ | ~ | 0.5/6 |
| Purism Librem 5 USA | USA, $1,999 | ✗ | ✗ | ~ | ✗ | ✗ | ~ | 1/6 |
| NitroPhone (Nitrokey) | Germany, €630–€1,500 | ✗ | ✗ | ✗ | ✗ | ✗ | ~ | 0.5/6 |
| Necunos NC_1 | Finland, €1,199 | ✗ | ✗ | ✓ | ~ | ✗ | ✓ | 2.5/6 |
| KATIM Phone | UAE, ~$800–$2,000 | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | 0/6 |
| Sirin Labs Solarin | Defunct, was $14,000 | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | 0/6 |
| Military / Government | ||||||||
| Sectra Tiger/S 7401 | Sweden, NATO SECRET | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | 1/6 |
| GD Sectéra vIPer | USA, NSA Type 1 | ✗ | ✓ | N/A | ✗ | ✗ | ✗ | 1/6 |
| GSMK CryptoPhone | Berlin, dual-algo | ✗ | ✗ | ✗ | ✗ | ✗ | ~ | 0.5/6 |
| R&S TopSec Mobile | Germany, BSI VS-NfD | ✗ | ✓ | ✗ | ✗ | ✗ | ✗ | 1/6 |
| Boeing Black | USA, classified | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | 0/6 |
| goTenna Pro X2 | USA, ~$1,000–$2,000 | ✗ | ✓ | ✓ | ✗ | ✗ | ✗ | 2/6 |
| Criminal Encrypted Networks (all shut down) | ||||||||
| EncroChat | Shut down 2020, 60K users | ✗ | ✗ | ✗ | ~ | ✗ | ✗ | 0.5/6 |
| Sky ECC | Shut down 2021, 170K users | ✗ | ✗ | ✗ | ~ | ✗ | ✗ | 0.5/6 |
| ANOM (FBI honeypot) | Shut down 2021 | ✗ | ✗ | ✗ | ~ | ✗ | ✗ | 0.5/6 |
| Phantom Secure | Shut down 2018 | ✗ | ✗ | ✗ | ✗ | ✗ | ✗ | 0/6 |
| Ghost | Shut down 2024 | ✗ | ✗ | ✗ | ~ | ✗ | ✗ | 0.5/6 |
| Hardware Wallets (for reference — closest SE architecture) | ||||||||
| Keystone 3 Pro | 3 SEs, 2 vendors | ✗ | ✓ | ✓ | N/A | ✗ | ~ | 2.5/6 |
| Coldcard Mk4 | 2 SEs, 1 vendor | ✗ | ✓ | ✓ | N/A | ✗ | ~ | 2.5/6 |
✓ = fully achieved · ~ = partial · ✗ = not present · N/A = not applicable. The tilde (~) for Bittium indicates three encryption types (disk, VPN, E2E) but these operate at different network layers, not as three per-message cryptographic envelopes. For GrapheneOS, open source is partial because Titan M2 firmware remains proprietary.
Finland · ~€2,000 · NATO Restricted · NCSA-FI Confidential · FIPS 140-2
The strongest certified smartphone. Dual-boot hardened Android, dedicated secure element, always-on tamper monitoring, privacy mode button, TEMPEST-tested. Achieves three encryption types: disk encryption, VPN tunnel via Bittium Secure Suite, and E2E via Bittium Secure Call. But all three operate at different network stack layers — not as three cryptographic envelopes around each message. Its Qualcomm Snapdragon 670 integrates a standard baseband without physical separation. Proprietary, closed-source firmware. Score: 0.5/6.
Sweden · Classified · NATO SECRET · SCIP interoperable · Quantum-resilient
The gold standard for NATO secure mobile communications. Custom-built handset with TEMPEST verification, tamper response, Red/Black hardware separation. Deployed across the majority of European NATO nations and now claims quantum-resilient cryptography. Uses classified algorithms rather than layered commercial crypto. But: proprietary, closed-source, requires cellular baseband, mandatory identity binding. The military's highest-assurance approach and SimpleGo's polar opposite in design philosophy. Score: 1/6.
Berlin · €1,500+ · Dual-algorithm · Baseband Firewall 2.0
The only phone using two symmetric algorithms simultaneously: AES-256 and Twofish as parallel counter-mode stream ciphers with 4096-bit Diffie-Hellman key exchange. Its patented Baseband Firewall 2.0 monitors baseband activity and detects IMSI catchers. Source code available for security review — unique among high-security phones. But: still runs Android, still has a baseband processor (monitored, not eliminated), no secure elements, and dual encryption is not triple-layer per-message. Score: 0.5/6.
The architectural insight: Existing devices cluster in two distant regions. High-assurance military devices (Sectra Tiger, Sectéra vIPer) use classified algorithms with tamper response, TEMPEST shielding, but run on proprietary, closed-source, baseband-equipped platforms with mandatory identity. Open-source mesh devices (Meshtastic, Reticulum) run bare-metal firmware with no baseband and full transparency, but have zero hardware security and basic encryption. SimpleGo occupies the space between these clusters — combining the cryptographic sophistication of the military domain with the openness and baseband elimination of the privacy domain. No other device or published concept exists in this design space.
The SimpleX SMP protocol underwent a comprehensive cryptographic design review by Trail of Bits — one of the world's leading security audit firms. 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. Every line of cryptographic code is publicly auditable on GitHub. We plan to commission an independent security audit of the C implementation once the protocol stack is feature-complete.
All source code, protocol documentation, and hardware schematics are published under open-source licenses. Security claims that can't be independently verified are marketing — not engineering.
Three security tiers. Three threat models. One codebase. See the devices that run this cryptographic stack.
SimpleGo implements the most advanced per-message encryption architecture available in any consumer device. Each message passes through four independent cryptographic layers: Layer 1 uses Double Ratchet with X3DH key agreement providing perfect forward secrecy and post-compromise security. Layer 2 applies per-queue NaCl cryptobox encryption using X25519 Diffie-Hellman key exchange with XSalsa20 stream cipher and Poly1305 authentication. Layer 3 adds server-to-recipient NaCl encryption preventing traffic correlation even if TLS is compromised. Layer 4 adds a forwarding-to-destination onion routing envelope for IP address protection via 2-hop private message routing.
No other messaging protocol implements comparable four-layer per-message encryption. Signal uses Double Ratchet plus TLS for two layers. WhatsApp uses the Signal Protocol with a single encryption layer. Matrix uses Olm and Megolm plus TLS. SimpleX Protocol as implemented in SimpleGo is the only protocol with four cryptographic envelopes around every single message, plus TLS 1.3 transport security across all relay hops.
The implementation runs on bare-metal firmware using mbedTLS for cryptographic operations, with hardware random number generation from the ESP32-S3 TRNG. Content padding to 16 kilobyte fixed block size is applied at each layer to prevent message length analysis. The cryptographic implementation has been verified byte-for-byte against the official Haskell reference implementation.
Future roadmap includes CRYSTALS-Kyber post-quantum key encapsulation for resistance against quantum computing attacks, NVS encryption with eFuse-derived keys for secure persistent storage, and integration with hardware secure elements for key storage in Models 2 and 3.
Double Ratchet encryption hardware, X3DH key agreement embedded device, XSalsa20 Poly1305 implementation, NaCl cryptobox ESP32, forward secrecy messaging device, post-quantum encryption hardware, four-layer per-message encryption, SimpleX Protocol cryptography explained, how SimpleX encryption works, most secure encryption protocol comparison.