One system, not an app

Five components. One system.

A hardened phone that goes quiet, a gateway you hold, a messenger with no number, infrastructure that rebuilds itself, and a Tor admin brain. They are not five products — they are one air-gapped ecosystem, and each part is only as useful as the gap it serves.

The quiet endpoint

GuardTalkOS — a phone that goes quiet.

GuardTalkOS is a hardened, GrapheneOS-based build stripped to almost nothing — Wi-Fi-only, gateway-only, no Google services, no extra attack surface. It is the deliberately minimal endpoint of a larger system.

GuardTalkOS is a GrapheneOS-based build, building on the work of the upstream hardened-Android project at grapheneos.org. GuardTalk is an independent project, not affiliated with or endorsed by GrapheneOS. GuardTalkOS then closes the gap GrapheneOS names — the network level — by routing everything through the gateway.

Attack surface is removed, not merely disabled: no Play Services, no browser, no Bluetooth, no NFC, no USB debugging, no location services, no sideloading. Fewer radios and fewer apps mean fewer ways in. Verified boot confirms the system you run is the system you flashed.

This reduces software attack surface; it does not protect against firmware or baseband implants beneath the operating system. That limit is stated in the threat model.

baseGrapheneOS-derived
networkWi-Fi to gateway only
radios removedBluetooth · NFC · cellular data
noPlay Services · browser · sideload
bootverified boot
supportedPixel 8 / Pixel 9
version0.1.0 GuardTalkOS
distributionTor-only

The only bridge

The Gateway — the bridge you hold.

A pocket-sized appliance on BPI-R3 / BPI-R4 hardware that stands between your phone and the world. Nothing reaches the internet except through it — and it is yours. Each mechanism below is paired with its limit.

Full-disk encryption

Protects against

Data at rest on a seized gateway — LUKS2 / argon2id / AES-256-XTS, unlocked by a biometric key you carry separately.

Its limit

It cannot protect a device seized while unlocked and running. See the threat model.

Kill switch

Protects against

Clearnet leaks — nftables drops all traffic the moment the tunnels drop, so nothing escapes unprotected.

Its limit

It protects the network path, not a compromised endpoint behind it.

Per-device VLAN isolation

Protects against

Lateral movement between devices — each device sits on its own isolated VLAN, so one cannot reach another.

Its limit

Isolation on the gateway does not harden the devices themselves.

DNS & threat blocking

Protects against

Known malicious and newly-registered domains — resolved against blocklists before any connection is made.

Its limit

A domain not yet on any list will not be blocked by reputation alone.

TLS fingerprinting & IDS

Protects against

Documented spyware traffic — JA3 / JA4 TLS fingerprinting and Suricata rules for known families, plus C2 beacon detection.

Its limit

A novel, well-resourced 0-day may evade signatures it has never seen.

Nightly key rotation

Protects against

Long-lived key compromise — gateway keys rotate nightly, shrinking the window any single key is useful to an adversary.

Its limit

Rotation limits exposure over time; it does not undo a key compromised within the window.

No number, no server record

Messenger — talk with no number, no server, no trace left behind.

GuardTalk Messenger is a Jami-based peer-to-peer messenger. It needs no phone number, runs on no central server a vendor can read, and encrypts every message, call, and file with quantum-resistant cryptography (QPC) — built to remain secure against both classical and future quantum adversaries. messenger

  • No phone number. Identities are cryptographic, not tied to a SIM or a directory an adversary can query.
  • Quantum-resistant encryption (QPC). Messages, calls, and files are end-to-end encrypted with algorithms designed to resist both classical and quantum attacks — readable only by the people in the conversation.
  • Peer-to-peer over OpenDHT. Built on Jami, peers find each other across a distributed network — no central server the vendor can read or be compelled to hand over.
  • Private push. No Google or Apple push relaying who is contacting whom.
  • Open source. The client and protocol are inspectable, so trust is something you can check.

We adopt Signal's clarity and privacy-by-default framing collegially; GuardTalk runs a harder model and never claims more than its upstreams would.

Honest about metadata

End-to-end encryption hides message content, not the fact that two parties communicated. A peer-to-peer design over a distributed hash table still exposes some connection metadata to the network and to the peers you reach. Routing over Tor hides network location from most observers, but a global passive adversary watching both ends can still attempt traffic correlation. We keep no server record of who spoke to whom; residual metadata and its limits are set out in the threat model.

Rebuilds itself, then goes dark

Infrastructure — rotating, and seizure-aware.

The supporting cloud rebuilds itself on a short cycle and is designed to withdraw access if a device is seized. Mechanisms are described responsibly, not operationally.

Auto-rotating cloud

Protects against

Persistent infrastructure footholds — servers rebuild on a 3-day rotation, so a foothold has a short life.

Its limit

Rotation shortens exposure; it does not stop an adversary active within the cycle.

Seizure failsafe

Protects against

A seized device unravelling the network — a deployed device that fails to check in for 12 hours is automatically wiped, and its supporting infrastructure self-destructs.

Its limit

It cannot recover data already exfiltrated before the failsafe triggers.

Nightly WireGuard rotation

Protects against

Long-lived tunnel keys — WireGuard keys rotate nightly, limiting the value of any single captured key.

Its limit

Rotation bounds exposure over time, not a compromise inside the window. See the threat model.

Invisible, but critical

The Tor admin brain.

An onion-only operations console ties the system together. It is reachable only over Tor, is not public marketing, and exists to manage the fleet — provisioning devices, pushing threat-intelligence rules, and monitoring gateway health.

Its boundary is deliberate: admins manage devices, not message contents. The brain can see that a gateway is healthy or that a device has gone dark; it cannot read what anyone said. That separation is the point.

Operations console

reachable: Tor onion only

scope: devices, fleet health, rules

never: message contents

For the team-deployment view of this, see For teams.

One system. Prove it, then own it.

Every component resolves to a named mechanism and a stated limit. Verify them in source, or request access privately.