Data Protection

Q: How is my data encrypted?

Maexry encrypts all data at rest using AES-256-GCM via SQLCipher — the same standard used in banking and defense applications. But encryption alone is only half the story. What matters is the key architecture.

A single 256-bit Master Seed, generated by a cryptographically secure random number generator, is the root of all encryption. From this seed, nine purpose-specific keys are derived using HKDF-SHA256 with unique context strings — one for the database, one for your API keys, one for OAuth tokens, one for settings sync, and so on. Each key is cryptographically independent: compromising one does not compromise the others. The Master Seed itself is never held in memory beyond the initial unlock — it is derived, used to produce all nine subkeys, and immediately zeroized. On macOS, the subkey memory is pinned in RAM (mlock) to prevent it from being swapped to disk.

Q: Where are my encryption keys stored?

Your Master Seed is encrypted by a P-256 asymmetric key generated inside your device's Secure Enclave (Apple Silicon) or StrongBox (Android). This hardware key is physically non-exportable — no software, including Maexry, can read it. The Secure Enclave performs encryption and decryption operations internally; the key material never enters main memory.

To unlock your data, you authenticate with biometrics (Face ID, Touch ID) or your device passcode. The Secure Enclave decrypts the Master Seed, the app derives all nine subkeys, and the seed is immediately wiped from RAM. Operations that need the raw seed later (like exporting a backup) require a fresh biometric authentication each time.

Q: Can Maexry (or Maexry) read my data?

No — and this is not a policy claim. It is an architectural guarantee.

Your encryption keys exist only on devices you control. Maexry's servers store and relay encrypted blobs, but hold no key material. Even under a complete server compromise, an attacker would see only ciphertext indistinguishable from random noise. There is no "admin key," no escrow, no server-side decryption path. The Dark Blob backup is wrapped with a password only you know, using Argon2id with 64 MB of memory cost — brute-forcing it is computationally prohibitive. We designed the system so that "we cannot read your email" is a statement of mathematics, not trust.

Q: What happens if I lose my device?

You have two recovery paths, both designed so that Maexry never sees your keys:

Password Recovery (Dark Blob): During setup, you create an encrypted backup of your Master Seed protected by a password you choose. This backup is stored on our server as a "Dark Blob" — encrypted with Argon2id (64 MB memory, 3 iterations, 4 parallel lanes). On a new device, you enter your password, the blob is decrypted locally, and a fresh Secure Enclave key re-wraps the seed on the new hardware. Without the correct password, the blob is useless.

QR Key Exchange: If you still have another device, you can transfer the Master Seed directly. Device B generates an ephemeral key pair and displays the public key as a QR code. Device A scans it, computes a shared secret via ECDH, encrypts the seed, and sends it through a relay. Device B decrypts and stores it locally. The relay sees only encrypted data.

Q: How does multi-device sync work without exposing my data?

The key insight is deterministic key derivation. Every device that holds the same Master Seed derives the exact same nine subkeys — same seed plus same context string always produces the same key. This means Device A and Device B can independently encrypt and decrypt the same data without ever exchanging keys after the initial seed transfer.

Synced data — settings, classification results, intelligence data — is encrypted on the sending device with the appropriate HKDF subkey, uploaded as an opaque blob, and decrypted on the receiving device with the locally-derived copy of the same key. The server is a relay, not a participant. It stores and forwards blobs it cannot read.

Q: What is BYOK and why does it matter?

BYOK (Bring Your Own Key) means you connect your own API key from a supported provider — OpenAI, Anthropic, or Google — and Maexry uses it to classify and analyze your email. Your API key is encrypted at rest with a dedicated HKDF subkey and sent directly to the provider over TLS. It never passes through Maexry's servers.

This matters for three reasons. First, privacy: your email content goes directly from your device to a provider you chose, under an agreement between you and them. Second, cost: you pay the provider's wholesale API rate (typically under $0.50/month for email classification) instead of a markup bundled into a subscription. Third, control: you can switch providers, use a local Ollama instance via the Bridge Engine, or disable cloud AI entirely.

Q: What happens to my data before it reaches an AI provider?

Before any email content is sent to a cloud AI provider, the Sentry engine — running locally on your device via llama.cpp with Metal GPU acceleration — scrubs personally identifiable information. Names, credit card numbers, social security numbers, and other sensitive data are redacted on-device before the request leaves.

Beyond redaction, Maexry's IntelligenceRouter enforces a hard privacy gate: tasks classified as PII-sensitive are architecturally blocked from routing to any remote engine. This is not a configuration setting that can be toggled off — it is a defense-in-depth check compiled into the routing logic. The router sets a requires_redaction flag for all remote-bound tasks, and the privacy gate rejects PII-sensitive tasks from remote engines entirely, even if a user attempts to override the routing preference.

Q: Who makes Maexry?

Maexry is built by Maexry LLC, a US company based in Atlanta, Georgia. We believe trust starts with accountability — you should know exactly who is behind the software that handles your email. Maexry is a registered US entity, subject to US law, with an identifiable team and a physical presence. We chose to build Maexry's zero-knowledge architecture precisely because we believe the best way to earn trust is to remove the need for it: if we cannot access your data by design, the question of whether you should trust us becomes moot.