SECURITY

Built from the ground up
for hostile environments.

Our threat model assumes sophisticated adversaries โ€” state-level actors, well-funded attackers, and insider threats. Here's how we design against them.

๐Ÿ”

End-to-End Encryption

All files are encrypted client-side using AES-256-GCM before they are transmitted to our servers. Your encryption keys never leave your device. We store only ciphertext.

Even if our servers were seized, the data would be mathematically useless without your key. We cannot decrypt your files. Law enforcement cannot compel us to decrypt your files. We simply do not have the keys.

  • โœ“AES-256-GCM authenticated encryption
  • โœ“Keys derived from your password using Argon2id
  • โœ“Forward secrecy on all connections
  • โœ“No plaintext ever transmitted or stored
๐Ÿง…

Tor Hidden Service (.onion)

Your vault is accessed via a Tor hidden service โ€” a .onion address that routes traffic through the Tor anonymity network. This means your IP address is never revealed, even to our servers.

Tor hidden services also provide protection against server-side deanonymization. We cannot log your IP even if we wanted to, because Tor hidden services never receive the client's real IP address.

  • โœ“Full Tor circuit for every connection
  • โœ“Server IP address also protected
  • โœ“Resistant to network-level surveillance
  • โœ“Works with Tor Browser โ€” no configuration needed
๐Ÿ”‘

Zero-Knowledge Authentication

We use a zero-knowledge password protocol (SRP โ€” Secure Remote Password). This means your password is never sent to our servers, even during login. We verify that you know your password without ever seeing it.

If our authentication database were compromised, an attacker would find no passwords โ€” not even hashed ones they could crack. We simply don't store them.

  • โœ“SRP-6a zero-knowledge password protocol
  • โœ“No password hashes stored on server
  • โœ“Resistant to server-side credential theft
  • โœ“No password recovery possible โ€” by design
๐Ÿ“ต

No-Log Policy

We do not log IP addresses, connection times, access patterns, or file metadata. Our systems are configured to avoid generating logs in the first place โ€” because logs that don't exist can't be subpoenaed.

This is not a policy we can be pressured to change retroactively. The architecture makes logging technically impractical for most sensitive data.

  • โœ“No IP address logging
  • โœ“No connection timestamp logging
  • โœ“No file access pattern logging
  • โœ“No metadata retained after operations complete
๐Ÿ’พ

Offline Primary Storage & Encrypted Backups

Our primary storage tier is air-gapped and offline during normal operations. Data is only accessible during brief, audited synchronization windows. This means that even a successful server compromise yields only stale, encrypted data.

Backups are encrypted with independent keys and stored in separate physical locations. A compromise of one location does not compromise your data.

  • โœ“Air-gapped primary storage
  • โœ“Regular encrypted backups to separate locations
  • โœ“Backup keys independent of primary keys
  • โœ“Backup access requires multi-party authorization

A note on transparency

We believe in being honest about what we can and cannot protect against. No system is perfectly secure. If you are facing a sophisticated, well-resourced adversary, we recommend combining SealedCitadel with other operational security practices. Compartmentalize. Use Tor Browser. Minimize your digital footprint. We are one layer of a defense-in-depth strategy.