Threat model & honest limits
What Shortwave protects against, what it doesn't, and the honest caveats.
Threat model & honest limits
What "secure" means here
Content confidentiality you can trust — no one reads your words — with clean devices.
This is achievable and is what Shortwave delivers via NIP-44 (Cure53-audited, ChaCha20-Poly1305) wrapped in NIP-59 gift-wrap.
Threats covered
| Threat | Coverage |
|---|---|
| Eavesdropping on message content | Strong — NIP-44 E2E; no relay ever sees plaintext |
| Platform shutdown / service termination | Strong — no single owner; relay list is swappable; self-host optional |
| Government/ISP blocking one relay | Strong — multi-relay publish; fallback to radio tier |
| Impersonation (someone posing as a contact) | Moderate — verify pubkeys out-of-band on first add; pin contact pubkeys |
Threats NOT fully covered (honest)
Metadata
Gift-wrap (NIP-59) hides message content, sender identity, kind, and tags from relays. But a relay still sees:
- A
#precipient tag (who the message is for) - Event size and timing
This is a deliberate trade. Deep metadata anonymity (Tor-grade) would require always-on routing infrastructure that conflicts with the "simple for a small circle" goal. The choice is documented, not hidden.
Forward secrecy (NIP-44)
NIP-44 does not provide forward secrecy. If a secret key is later compromised, all past messages encrypted with that key are readable.
Upgrade path: replace 1:1 NIP-44 with a 2-person MLS group (RFC 9420, full PCS + FS). Queued for a future milestone. For the current threat model (content confidentiality with clean devices), NIP-44 is sufficient.
Endpoint security
E2E is only as safe as the two endpoint devices. A compromised device = game over regardless of transport security. Ephemerality helps — nothing is stored at rest to seize.
Hosted web app delivery
The web app itself is served over HTTPS from Vercel. A state-level attacker who can compel or compromise the host could serve modified JavaScript that exfiltrates keys before encryption. This is the standard "web app crypto" caveat and applies to all browser-based E2E tools (Signal Web, ProtonMail, etc.).
Mitigation: the Rust core (resilient-comms) is the hardened path. The web app is convenience for everyday use; for adversarial conditions use the Rust CLI or the Pi appliance (no HTTPS delivery surface).
Nation-state active targeting
A nation-state actively targeting you specifically is a higher bar than stated. Shortwave is designed for censorship + surveillance resistance at the ISP/platform level, not for hiding from a dedicated intelligence operation against an individual.
What helps most
- Clean devices. No malware, no stalkerware, no unlocked screen.
- Out-of-band key verification. When adding a contact, verify their pubkey via a separate channel (Signal, in person, printed QR).
- Self-hosted relay. Eliminates third-party relay metadata logging.
- Pi appliance. Removes the hosted-app-delivery attack surface entirely.
- Ephemerality. Nothing archived at rest = nothing to seize.
Signature verification
A known NIP-44 attack vector (documented in Black Hat / EuroS&P 2025, eprint.iacr.org/2025/1459) is plaintext DM recovery via skipped signature checks + auto link-previews. Shortwave's client rules:
- Always verify every event signature before processing.
- Never auto-fetch link previews on encrypted content.
- Prefer AEAD (ChaCha20-Poly1305) wherever we control the crypto — NIP-44 v2 satisfies this.
Australia's Assistance & Access Act
Australia's AA Act can compel a domestic "designated communications provider" to add capabilities or provide assistance. The risk is low for this specific tool (it is not a commercial service, it is open-source, and the crypto is standard audited NIP-44) but it is real and noted. If this becomes material: consider jurisdiction for hosting + relay infrastructure.