Plain-language summary

AliasCloak is designed so mailbox messages, chat content and files are end-to-end encrypted for participant keys, while the server still needs limited routing and operational metadata. A conventional email address or phone number is not required to create a generated mailbox.

Private keys and sessions

Mailbox private keys are intended to remain on the user’s device. The current production architecture can require TOTP for new or untrusted sessions after two-factor authentication is enabled. A successful verification can establish a trusted-device token so normal background syncing does not require an authenticator code every time.

Encrypted backups

Current AliasCloak backup exports can be encrypted locally with AES-256-GCM using a key derived from a user passphrase with PBKDF2-SHA-256. The passphrase is not sent to AliasCloak. The confirmed TOTP secret is deliberately excluded from new backup exports.

Information used for delivery

The service still needs operational data such as mailbox identifiers/public keys, delivery state, timestamps, storage/quota accounting, session records, block/receive settings, and enough routing metadata to deliver encrypted content. End-to-end encryption reduces content visibility; it does not mean the server has zero metadata.

Retention

AliasCloak is designed as a limited-retention delivery system rather than a permanent archive. In the current production build, one-shot messages have a hot-retention cutoff and a separate hard expiry. A deployment can keep still-unacknowledged ciphertext on primary storage for seven days and, when configured, move it to encrypted cold storage for another 30 days. Chat uses a separate retention policy. Healthcare organizations must confirm the deployed settings and move records that must be retained into an approved system of record.

Payments and annual aliases

Core generated mailboxes are free. Optional custom aliases are annual leases with scarcity-based pricing; shorter aliases cost more. Stripe/payment records can create a link between a payer and an alias purchase even though message content remains end-to-end encrypted.

What privacy architecture does not solve

  • A compromised browser, device or operating system.
  • Screenshots, copied plaintext or downloaded files.
  • Incorrect recipients or social engineering.
  • HIPAA administrative requirements, BAAs or workforce policy.
  • Records-management and legal-retention duties.

Healthcare use

Do not treat end-to-end encryption as a HIPAA certification. HHS says a cloud provider can still be a business associate when it maintains encrypted ePHI on behalf of a regulated entity, even if it lacks the decryption key. Confirm the actual vendor relationship, BAA requirements, risk analysis, endpoints, access and records process before ePHI use.