The defence stack

Security you can name — and check

No "military-grade" adjectives. Here are the actual mechanisms, what each one does, and where each one ends.

How to read this page

Every mechanism, with its limit attached.

No mechanism on this page is absolute. Each one names a technique, states what it protects against, and states where it ends — and the threat model bounds all of it. If a protection can't be linked to a mechanism and a limit, it isn't here.

The reading order

What it protects against, then its limit. The limit always links back to the threat model — read both before you trust either.

The network boundary

Where your traffic stops, and where it can't.

The air gap & kill switch

network · live
Protects against

Direct phone-to-internet exposure. The phone's modem stays off; the gateway is the only bridge. If the tunnels drop, nftables drops all traffic so nothing escapes unprotected — no clearnet leak.

Its limit

It guards the network path, not a compromised endpoint behind it. The gateway and the people you talk to are still endpoints that can be attacked. see the threat model

VLAN isolation

network · live
Protects against

Lateral movement between devices on the gateway. Each connected device sits on its own isolated segment, so one device cannot reach or observe another across the bridge.

Its limit

Isolation is between segments, not within a single compromised device — a device already implanted is still implanted. see the threat model

DNS, typosquat & NRD blocking

network · live
Protects against

Known-bad resolution. The gateway blocks DNS to flagged domains, typosquats, and newly-registered domains (NRD) commonly used to stage delivery and exfiltration.

Its limit

Blocklists catch the documented and the patterned, not a clean domain an adversary has never burned. see the threat model

QUIC blocking

network · live
Protects against

Opaque transport. QUIC is blocked so that traffic falls back to paths the gateway can actually inspect — blocking it is what enables the inspection the other mechanisms depend on.

Its limit

Inspection is of the transport, not of end-to-end encrypted content — it sees shape and metadata, not message bodies. see the threat model

The device you hold

Encryption, and the key you carry.

Full-disk encryption & the biometric key

device · live
Protects against

Data at rest on a seized device. The disk is encrypted with LUKS2 · argon2id · AES-256-XTS, unlocked by a biometric key you hold — not a key we hold.

Its limit

It cannot protect a device seized while unlocked and running; at-rest encryption only protects what is at rest. see the threat model

Duress detection

device · live
Protects against

A coerced unlock. A separate panic credential, entered instead of your own, triggers a cryptographic wipe of the local keys — so a forced unlock surrenders an empty device rather than your data.

Its limit

It cannot recover data already copied off the device, and it does not protect you under physical coercion beyond the wipe itself. see the threat model

The 12-hour failsafe / deadman

device · live
Protects against

A quietly seized device kept for later analysis. A device that fails to check in for 12 hours is automatically wiped, so a held device unravels less of the surrounding system.

Its limit

It bounds what a delayed seizure yields; it cannot undo an extraction that already completed inside the window. see the threat model

The messenger

Quantum-resistant encryption, no server required.

QPC end-to-end encryption

messenger · live
Protects against

Interception of message content, calls, and file transfers — both now and by an adversary who stores today's ciphertext to decrypt once quantum computers mature. GuardTalk Messenger encrypts with quantum-resistant algorithms (QPC), so the value of harvested ciphertext does not increase as quantum capability grows.

Its limit

Quantum-resistant encryption protects content in transit. It does not protect against endpoint compromise, metadata (who communicated with whom), or a device seized while unlocked. see the threat model

Detection & inspection

What the gateway watches, and what it can miss.

JA3 / JA4 TLS fingerprinting

detection · live
Protects against

Tooling that announces itself in its TLS handshake. JA3 / JA4 fingerprints are matched across four enforcement modes — observe, log, alert, block — so known client signatures can be flagged or dropped.

Its limit

A fingerprint matches what has been catalogued; a tool that mimics a common client can blend in. see the threat model

Suricata IDS

detection · live
Protects against

Documented spyware families. Suricata runs a maintained rule set covering documented spyware families — the full set is published on transparency.

Its limit

Signatures catch what has been seen before; a novel, well-resourced 0-day may evade a rule that has never met it. see the threat model

C2 beacon detection

detection · live
Protects against

The phone-home pattern of an implant. Periodic, low-volume callbacks to command-and-control (C2) are flagged by their timing and shape, even when the destination itself looks ordinary.

Its limit

An implant that beacons rarely, jitters its timing, or hides in normal traffic raises the cost of detection but does not make it certain. see the threat model

Moving target

Rotation, so nothing stays still long enough.

Nightly WireGuard rotation

rotation · live
Protects against

A static tunnel an observer can study over time. WireGuard keys rotate nightly (~24h), shortening the window any single key is exposed.

Its limit

Rotation limits exposure within an interval; it does not defeat an adversary observing both ends of the path for end-to-end correlation. see the threat model

3-day infrastructure rotation

rotation · live
Protects against

Long-lived infrastructure an adversary can map and target. The supporting cloud rebuilds itself on a short cycle (~72h), so the surface an adversary studied yesterday may not exist today.

Its limit

Rotation raises the cost of mapping the infrastructure; it does not protect a single endpoint compromised between rebuilds. see the threat model

Named mechanisms are only half of it.

Read where every one of them ends, then check the rule sets and source for yourself.