Threat Model & Security Notes
Nyxen is designed for privacy, not invincibility. This document defines what Nyxen actually protects you from — and what remains your responsibility. It’s a practical threat model, not a marketing promise.
1. Purpose
The goal of Nyxen’s security model is simple: to minimize digital residue from sensitive collaboration and communication.
That means:
No permanent logs.
No plaintext data in infrastructure.
No trust in Nyxen itself beyond relay uptime.
No illusion that encryption can fix poor operational security.
[!NOTE] Nyxen’s architecture limits what can leak, not what users can do. Security begins at the edge — your device, your discipline, your network.
2. Threat Model Summary
Server compromise
Relay or database breach
✅
No plaintext content; ciphertext deleted on TTL/burn
Metadata leak
IP, access logs
⚠️
Minimized; mitigated with Tor mode
Traffic interception
MITM / passive network surveillance
✅
TLS 1.3 + AES-GCM + optional Tor routing
Key compromise (server)
Extraction from backend
✅
Keys never sent to server
Key compromise (client)
Malware, keylogger, memory dump
❌
Out of scope; endpoint risk
Human error
Shared key in wrong channel
❌
Social/operational risk
Local logging
Screenshots, clipboard, screen capture
❌
Cannot be mitigated in software
Replay / tampering
Resend old ciphertext
✅
Nonce + integrity tag validation
Accidental retention
Forgotten files or caches
⚠️
Local wipe triggered, but browser persistence risk remains
Anonymity / identity link
IP correlation
⚠️
Use Tor mode for high-anonymity ops
3. Security Goals
Confidentiality
Only authorized peers can read content.
Integrity
Encrypted content cannot be modified without detection.
Ephemerality
Everything disappears on time or command.
Minimal metadata
Routing data never expands to analytics.
Pseudonymity
Nyxen doesn’t require accounts or personal info.
[!TIP] Nyxen replaces “access control by identity” with “access control by possession.” Whoever holds the key has access. That’s the model.
4. Security Guarantees
✅ Guaranteed by Architecture
End-to-end encryption for all primitives (AES-GCM, derived per-context keys).
Automatic TTL enforcement and cascade burn on expiry.
Zero plaintext on Nyxen servers.
No stored credentials, user accounts, or persistent identity maps.
Enforced minimal metadata (TTL, routing only).
Immutable non-recoverability after burn/expiry.
Same crypto model on clearnet and Tor.
⚠️ Partially Mitigated
IP-level anonymity (stronger via Tor).
Browser cache behavior (handled by app but dependent on user agent).
Time correlation across channels (e.g., user activity patterns).
Physical endpoint access (if device compromised).
❌ Not Mitigated
Local screen recording, screenshots, or transcript saving.
Compromised or monitored device OS.
Intentional key sharing or human error.
Network-level capture after local decryption.
5. Data Lifecycle (Security Flow)
[Create Object]
↓
Encrypt (Client)
↓
Send Ciphertext to Relay
↓
Relay stores (TTL countdown)
↓
Expire or Burn
↓
Relay purges + Clients wipe keys
↓
Nothing recoverableBurn Signal Structure
{
"context_id": "C-492",
"burn": true,
"timestamp": "2025-11-11T22:00:00Z"
}Relay Behavior
Purges ciphertext immediately.
Broadcasts burn signal to connected clients.
Deletes local cache.
Client Behavior
onBurn(contextId) {
clearLocalStorage(contextId);
revokeKeys(contextId);
showNotice("This Nyxen context has been destroyed.");
}6. Cryptographic Standards
Symmetric Encryption
AES-GCM-256
Key Derivation
HKDF (SHA-256)
Randomness
Web Crypto API / libsodium
Transport
TLS 1.3 / DTLS-SRTP
Optional PQ Transition
Hybrid Kyber + X25519 (research stage)
Keys and nonces are never reused. All payloads are authenticated.
[!NOTE] No compression or dynamic content encoding occurs before encryption to prevent CRIME/BREACH-style leaks.
7. Network Topology
Relays are stateless message brokers.
Each relay enforces TTL locally.
Data replication between relays uses encrypted payloads only.
No relay sees decrypted content or cross-context links.
Diagram:
[Client A] ←TLS→ [Relay 1] ←TLS→ [Relay 2] ←TLS→ [Client B]
Ciphertext-only path
No plaintext, no keys, no inspection8. Attack Scenarios
Scenario 1 — Relay Breach
Outcome: Attacker obtains ciphertext. Mitigation: No decryption possible; TTL deletion still removes data.
Scenario 2 — Compromised Client
Outcome: Attacker gains key in memory. Mitigation: None; Nyxen cannot secure a compromised endpoint.
Scenario 3 — Key Reuse Attempt
Outcome: Decryption fails (nonce & auth tag mismatch).
Scenario 4 — Traffic Correlation
Outcome: Attacker infers timing relationships. Mitigation: Use Tor; randomize TTLs; stagger sends.
Scenario 5 — Phishing or Fake Links
Outcome: User enters fake Nyxen URL.
Mitigation: Always verify .vip or .onion domain and TLS certificate.
9. Security Checklist for Users
Keys
Never share via untrusted channels. Split keys if possible.
Devices
Keep OS updated; use trusted hardware.
Network
Use VPN or Tor for added anonymity.
Storage
Don’t export Nyxen data. Treat local files as sensitive.
Verification
Always confirm domain before sharing.
TTL Discipline
Set shorter TTLs than you think you need.
[!TIP] Paranoia is a feature, not a flaw.
10. Compliance & Legal Position
Nyxen is a privacy infrastructure, not a censorship-avoidance or data-hiding tool. It is designed for legal, ethical use by professionals requiring ephemeral, encrypted collaboration.
Examples of legitimate uses:
Security and incident response teams
Legal firms working on sensitive mergers
Journalists protecting sources
Product teams handling unreleased IP
NGO or field operations requiring transient comms
[!WARNING] Nyxen prohibits and monitors for abuse indicators at the network level (volume, pattern anomalies) — not content. Malicious use results in access termination.
11. Summary
Nyxen provides strong privacy and cryptographic assurance, not perfect anonymity.
Encryption
End-to-end, enforced
Data retention
None
Logs
None after TTL
Trust requirement
Minimal
Endpoint security
User responsibility
Operational discipline
Required
12. The Ethos
Nyxen’s defense philosophy:
If it doesn’t exist, it can’t be compromised.
Everything else is just implementation detail.
Last updated