Cryptographic Proof

Not Policy

Assume GitHub, our relay, a factory and the network are all hostile. Here is why you are still safe, and what is not shipped yet.

  • ML-DSA-65 identity
  • ML-KEM-768 sealing
  • Your phone is the mailbox
  • Cloudflare edge
  • Signed, hash-named bins
  • Open source firmware

Overview

If this happens, this stops it

GitHub is hacked

Unsigned builds never install. Signing keys stay offline.

A factory disk is stolen

Mail is ciphertext. Bins are named by hash and signed.

Our relay is breached

It holds sealed boxes it cannot open, deleted after delivery.

A rogue Wi-Fi poses as your device

The device key must match the registry. Fakes are refused.

A device is stolen

Revoke its key. One device is the whole blast radius.

A port is left open

Agents only dial out. Rules are signed by the owner.

A flood of traffic hits us

Cloudflare absorbs it at the edge. There is no origin server to find.

A bot scrapes our downloads

Bad user agents are refused. Limits apply per IP and per network.

Cloudflare edge

Attacks thin out before they reach us

Cloudflare's network takes the first hit. We add our own gates behind it.

Layers at the Cloudflare edge Hostile traffic meets five gates in turn: DDoS mitigation and TLS from Cloudflare, then bot filtering, rate limits and signature or session checks that we add. Less hostile traffic gets through at each gate. Real users pass. DDOS absorbedat the edge TLS HTTPS only,HSTS set BOTS bad agentsrefused LIMITS per IP andper account VERIFY sessions andsignatures hostile traffic real users CLOUDFLARE, AUTOMATIC WE ADD No origin to find: the site, API, relay and mail run on Pages, Workers and Durable Objects.
  • Pages
  • Workers
  • Durable Objects
  • D1
  • KV
  • R2
  • Email Routing
CloudflareDDoS mitigation, layers 3, 4 and 7
We setWildcard certificate: apex, *, *.threats
We setHSTS for one year on every page
We setDownload guard: bad agents get 403, floods get 429
We setMail API limits per hashed IP, and a daily signup brake
We setTurnstile on signup, when enabled
We setInbound mail screened with Cloudflare's SPF, DKIM, DMARC result
We setAdmin pages gated server-side, failing closed
We setSession cookies HttpOnly, Secure, SameSite
We setStripe webhooks verified by HMAC, constant time
We setRelease manifest signed with Ed25519
Not claimedCustom WAF rules, Bot Management, Cloudflare Access

Mail and pokes

Your phone is the mailbox

We carry sealed boxes. We keep no inbox.

How a message travels The sender's phone seals the message. The relay carries it and deletes it when the recipient's phone confirms. Only the recipient's phone opens and keeps it. SENDER signs and seals OUR RELAY carries, never opens YOUR PHONE opens and keeps sealed collected deleted once your phone says got it
Who can read what Mail and pokes are readable on your phone only. The relay holds them sealed. A factory disk does not hold them. Bins are verified by devices and only served, never altered, by a factory. YOUR PHONE OUR RELAY A FACTORY DISK Mail reads sealed not there Pokes reads sealed not there Bins verifies not there can't alter
  • 30 days max in the queue
  • 25 MB cap per person
  • Relay sees who, when, how big
  • Pokes expire in 7 days

Galaxy

Direct first. Relay if blocked.

A relay only ever sees ciphertext.

Galaxy connection paths Your phone connects directly to your device when it can. If a firewall blocks that, traffic goes through a relay, still encrypted end to end. PHONE DEVICE 1 · direct, when it can RELAY ciphertext only 2 · fallback, still encrypted end to end
  • No port forwarding
  • Revoke a share instantly
  • Ownership is a key on the device

Nexus and the Factory

Factories you do not have to trust

Every company gets three nexuses. Every factory replicates all three.

Three nexuses on an untrusted factory Phones and devices reach the device, mail and app nexuses on a factory. Only the device nexus holds the gateway keys. A stolen disk gives up ciphertext and hash-named, signed bins. PHONES & devices FACTORY · ANY LOCATION DEVICE NEXUS signed bins · named by SHA-256 keys here MAIL NEXUS sealed mail and backups no keys APP NEXUS app data · its own volume no keys A stolen disk: ciphertext and signed bins no signing key · no password · nothing to forge
  • Helm chart: infra/factory/charts/nexus
  • Extra mail drives allowed
  • Gateway keys mount on the device pod only

Firmware

A bin cannot be swapped

Two independent gates. A factory can withhold a bin, not change one.

The two gates a firmware bin must pass A real bin is signed offline, named by its SHA-256 on the nexus, and its signature is checked again on the device before it runs. A changed bin is refused at the nexus because its hash no longer matches, and rejected by the device because its signature fails. THE REAL BIN Buildfrom source Signoffline key Nexusname = hash? Devicesignature ok? Flashruns A CHANGED BIN Changedbin Nexushash ≠ name Devicebad signature Flashnever Firmware is signed with ML-DSA-65 over the SHA-512 of the image.

Post-quantum

What post-quantum costs, in bytes

Bigger signatures, built to outlast quantum computers.

Signature and ciphertext sizes Bar chart on a log scale. Ed25519 signature 64 bytes, RSA-4096 signature 512 bytes, ML-KEM-768 ciphertext 1,088 bytes, Falcon-1024 signature 1,280 bytes, ML-DSA-65 signature 3,309 bytes. bytes, log scale Ed25519 signature Lights devices today 64 RSA-4096 signature classical signature size 512 ML-KEM-768 ciphertext sealing mail and pokes 1,088 Falcon-1024 signature checkpoint signatures 1,280 ML-DSA-65 signature firmware, identity, gateway 3,309 classical, in use today post-quantum
  • FIPS 204 ML-DSA
  • FIPS 203 ML-KEM
  • SHA-256
  • Argon2id + AES-256-GCM backups

Alien Lights devices

Not your average WLED

Vanilla WLED, as most makers ship it, takes unsigned updates.

Vanilla WLED compared with Alien Lights firmware Five comparisons: OTA updates, who can claim a device, malicious usermods, a fake Wi-Fi endpoint and a stolen claim. VANILLA WLED ALIEN LIGHTS OTA update accepts any bin signed bins only Who can claim it first to ask owner proves it Malicious usermods survive resets not injected by OTA Fake Wi-Fi endpoint trusted by default key must match A stolen claim no way to revoke revoked, key is dead
  • Vanilla WLED: CWE-306, CVSS 10.0
  • Validated on 10+ devices
  • Firmware source

Optional: catch attackers instead of only blocking them.

The honeypot loop An attacker pushes a malicious bin. The device hashes it and replies that it verified. It never flashes. With opt-in, only the hash and metadata are reported. Attackerpushes a bin Devicehashes it Decoy reply"verified" Never flashedhash reported The attacker thinks it worked. The device stays on signed firmware. Opt-in only. Hash and metadata leave. No configs, no credentials.

Honest status

What is shipped and what is not

AvailableZero trust gateway and agent
AvailableNexus node, run with --nexus
AvailableAlien Queue and Poke
AvailableML-DSA-65 signed firmware
BuiltMail and nexus chart and filter
In developmentAlien VPN full tunnel
In developmentAntivirus app on the phone
PlannedMail backup to the mail nexus, in the app
PlannedPost-quantum identity in firmware
PlannedLedger copied through Nexus; per-company sequencing

Limits

What we do not protect

  • Malware with root on an unlocked phone
  • A lost recovery password. We hold no copy.
  • Metadata: who, when, how big
  • Outside email, readable at our edge for a moment
  • A factory withholding data. It can refuse, not forge.
  • Leaked offline signing keys
  • Your own gateway and factory machines. Their uptime and DDoS exposure are yours.
  • USB reflashing by someone holding the device. It wipes the identity.
  • App nexus data. It is isolated, and apps seal their own data.

Found a flaw? security@alienlights.net