At a glance
Which parts of your account are encrypted, and who can read them. Each row links to the section that explains it.
| Data | How it is protected | Who can read it |
|---|---|---|
| Files, notes and app data | Encrypted in your browser before upload | Your devices and the apps you approve for that folder |
| Mail between Seige accounts | End-to-end encrypted by the sender’s browser | The sender and the recipients |
| Incoming internet mail | Processed in memory, then encrypted to your key before it is stored | Seige during delivery; the stored copy needs your keys |
| Outgoing internet mail | Delivered over certificate-verified TLS; your sent copy is encrypted | Seige during delivery, and the receiving provider |
| Your password | Checked with OPAQUE and never sent to Seige | Only you |
| Ada and app AI requests | Sent in readable form for model processing; stored copies stay encrypted | Seige’s AI service and the model, for that request |
| Routing details | Not covered by content encryption | Seige: addresses, delivery status, timestamps, sizes and logs |
Encryption depends on your device and the application code your browser runs. Devices and updates explains what that means.
How password sign-in works
Your password stays on your device during normal account creation, password sign-in and password changes. Seige uses a protocol called OPAQUE to check that you know it without receiving it.
-
Your device
You enter your password
Your browser uses it to create a randomized sign-in proof.
Your password stays here -
Seige servers
Seige checks the proof
A successful check signs you in. Your browser can then download your encrypted key package.
Once you are signed in, your browser downloads a locked package containing your private account keys. It uses your password to open that package on your device. The keys inside let you read your encrypted mail, files and settings.
Proving your identity and unlocking your keys are separate steps. Seige can check the sign-in proof while the package is opened only on your device.
Why not send a password hash?
A hash is a value calculated from a password. If Seige accepted the same hash at every sign-in, that value would become another password. Someone who stole it could send it to sign in without knowing your original password.
OPAQUE uses a fresh cryptographic exchange for each sign-in. Its messages are tied to that exchange, so a recorded successful login cannot simply be sent again to sign in. Your browser proves that you know the password without handing over a reusable password hash.
Technical details of password sign-in
Seige uses OPAQUE with Ristretto255, TripleDH, SHA-512 and Argon2id. The server stores an OPAQUE registration record, the public account certificate and an encrypted account package. Password-based package unlocking uses a separately derived key. OPAQUE uses hash functions internally; the comparison above is about sending a fixed hash as a reusable sign-in credential.
Protocol reference: OPAQUE, RFC 9807.
How your keys are protected
Your browser creates your account keys when you sign up. The public key can be shared to encrypt data for you. Your private keys are needed to open it, so they are encrypted before upload and unlocked on your device.
How your password protects your keys
Seige stores your private keys inside an encrypted account package. Your plaintext password is not stored. Each package has its own random salt, which makes password-based key derivation different for every package.
Argon2id requires memory and computation for every password guess. An attacker has to do that work separately for each package; one precomputed password lookup cannot be applied across the database.
A strong, randomly generated password makes practical guessing infeasible. Predictable passwords are easier to guess, so use a strong, unique password. If someone obtains an encrypted package, offline guessing remains possible, with each guess subject to that package's Argon2id work.
Passkeys and remembered browsers
Supported passkeys can unlock your account using a secret created by your authenticator. Remembering a browser stores an encrypted copy of your account keys on that device. Opening that copy requires both a browser-held key and a secret released by Seige after authentication.
Technical details of key protection
Password-based unlocking uses Argon2id with 64 MiB of memory, three iterations and one lane, followed by HKDF-SHA-256 and AES-256-GCM. Each newly wrapped package has a random salt and nonce. Supported passkeys use WebAuthn PRF, HKDF and AES-256-GCM.
Remembered-browser material is encrypted in two layers: one requires a non-exportable browser key, the other an authenticated server share. Neither alone opens that local copy. The separate password-protected package remains subject to offline guessing.
How encryption works
Your device encrypts private content before sending it to storage. An authorized device or app uses the right keys to make it readable again. Mail between Seige accounts follows this same pattern.
-
Your device
Encrypt
Your browser turns readable content into encrypted data.
-
Seige servers
Store
Seige keeps the encrypted content and encrypted key packages.
-
Your device
Unlock
Your browser unlocks your keys, checks the content and makes it readable.
Encryption keeps content unreadable without the right keys. Digital signatures let your browser check that content came from the expected signing key and has not changed. Messages with failed checks are rejected before display.
Which algorithms we use and why
Content, encryption keys and signatures need different kinds of protection. Seige uses OpenPGP through Sequoia to combine them.
-
AES-256-GCM keeps content private and detects
changes.
Files and messages can be large, so their encryption needs to be efficient. AES handles the content, and GCM lets the client detect tampering before accepting it. The 256-bit key provides a substantial margin against known conventional and quantum attacks.
Fresh random keys keep separate file encryptions from relying on one reused content key. Encrypting files in chunks lets the app process large files in manageable pieces.
-
ML-KEM-768 + X25519 protect the keys that unlock
content.
To let someone open a message or file, we need to protect its encryption key for the intended recipient. This is the job of the combined key-protection scheme; AES encrypts the content itself.
X25519 provides established protection against conventional attacks. ML-KEM-768 adds protection designed for quantum computers. Combining them reduces dependence on either method alone: the protected key is designed to remain secure if one component is broken while the other and the combination remain secure.
-
ML-DSA-65 + Ed25519 protect against forgery.
Anyone with your public key can encrypt something for you. Encryption alone therefore does not prove who created it. A digital signature lets your browser check that content was signed by the expected private key and has not changed.
Ed25519 provides an established signature method, and ML-DSA-65 adds quantum-resistant protection. Both components must verify, so breaking just one should not be enough to forge an accepted signature while the other remains secure.
Modified messages, malformed data and unsupported key profiles are rejected. Content encryption and signing operations reject classical-only keys. Recipient public keys come from Seige's account directory, which is part of the trust model.
Format references: OpenPGP v6, RFC 9580, and post-quantum OpenPGP, RFC 9980.
Envelope encryption: protecting the key as well as the file
Seige uses envelope encryption. A random key locks the content, and another layer of encryption protects that key. Both the encrypted content and its protected key can then be stored on the server.
This keeps encryption efficient for large files and separates file protection from access permissions. Folder keys let an approved app open files in that folder without receiving your private account key or access to unrelated folders.
-
1. On your device
Lock the file
Create a fresh random content key and use it to encrypt the file.
-
2. Still on your device
Protect the key
Put the content key inside file details encrypted to the folder's public key.
-
3. Send to Seige
Store both encrypted parts
Upload the encrypted file and its encrypted details. The content key is protected inside.
For your own files, your private account key unlocks the folder's keys. The folder's private key opens the encrypted file details, which contain the key needed to read the file. Connected apps receive only the folder keys you approve.
Technical details of envelope encryption
The file content key is a random AES-256-GCM key. It is stored inside an encrypted manifest alongside the file size, type and chunk integrity information. OpenPGP protects that manifest to the folder's public key using ML-KEM-768 + X25519 and AES-256-GCM. Owner folder-key material is encrypted to the account key; approved apps receive separately encrypted folder-key grants.
OpenPGP messages also use a random content key protected for the recipient. Mail between Seige accounts protects that key to the recipient's account key directly, without the file-storage folder layer.
What quantum resistance means
A sufficiently powerful future quantum computer could break some widely used encryption methods. Seige combines established methods with newer algorithms designed to withstand those attacks.
The post-quantum component is designed to keep protecting your encryption keys even if the traditional component is broken. Signatures also use both kinds of protection. This helps protect encrypted data that someone might collect today and try to read with a future quantum computer.
Seige applies this hybrid post-quantum protection to encrypted files, mail preferences and mail between Seige accounts, using protected content keys and digital signatures.
Technical details of quantum resistance
ML-KEM-768 supplies the post-quantum protection for encryption keys. Breaking X25519 alone should not reveal the combined key while ML-KEM and the combination remain secure. Both ML-DSA-65 and Ed25519 signatures must verify, so breaking Ed25519 alone should not allow a forgery while ML-DSA remains secure. AES-256 provides a substantial margin against known quantum attacks.
Algorithm references: NIST ML-KEM standard, NIST ML-DSA standard, and NIST guidance on quantum computing and AES.
How OAuth and the SDK limit app access
Connecting an app starts with your approval in Seige. OAuth is the permission protocol: it gives the app a connection for the access you approve. The Seige SDK is the library the app uses to request that access and work with encrypted data.
- The app requests its own folder, selected existing folders or AI access.
- You review the request on Seige's consent screen and choose what to allow. Your password is entered in Seige.
- The app receives a limited connection and the encrypted key grants for its approved folders. The SDK uses the app's own keys to open those grants.
You can open your account data using the keys unlocked on your device.
- Mail, files and notesYour private content
- Ada's memoryConversations and saved knowledge
- Other app foldersSeparate folder keys and approvals
- A folder you approveFor example, your recipes
Can open the approved recipes folder using its folder-key grant.
Its connection does not include your account key, unrelated folders or Ada's memory.
The SDK works within your permissions
The SDK handles encryption, decryption, signature checks and synchronization for the folders the app is allowed to use. Seige checks permissions on the server, and the app receives only the corresponding folder keys. Editing the SDK or guessing a folder ID does not create a new permission or supply its decryption key.
An approved app can read and copy the content it is allowed to open. The consent screen identifies whether it processes that data on your device or its own servers. Disconnecting it blocks further requests and replaces affected folder keys for future changes, as described in sharing access between apps.
Your access inside Seige
In your signed-in Seige workspace, you can browse your mail, files, notes, connected-app data and Ada's saved memory. Seige's built-in apps use the trusted account browser session to open that data with your keys. Third-party apps run outside this account workspace and use their own limited connections.
This is your access as the account owner, using your unlocked device. Encrypted storage remains encrypted on the server. Selected content becomes readable during the delivery or AI processing described in this page.
Technical details of OAuth and SDK permissions
Seige uses the OAuth authorization-code flow with PKCE and proof-of-possession access tokens through DPoP. PKCE helps bind code redemption to the client that started the connection. DPoP binds token use to a client key, so a copied token alone is insufficient to make an authorized request.
Server checks verify the live connection, token permissions, approved folder and allowed operation. The SDK verifies owner-signed key grants and signed storage records. User account keys and account-session credentials are not handed to the third-party app. The SDK is a protocol client; the permission boundary is enforced by server checks and cryptographic keys.
References: OAuth security guidance, RFC 9700, and proof-of-possession tokens, RFC 9449.
Mail delivery
Between Seige accounts
- Sender’s browser Encrypts the message before it leaves the device. Encrypted
- Seige Stores the inbox and sent copies, each encrypted to its owner’s keys. Encrypted
- Recipient’s browser Decrypts the inbox copy locally. Decrypted on the device
Incoming internet mail
- Sending server Delivers ordinary internet mail. Readable in transport
- Seige Processes it in memory and encrypts it to your public key before saving it. Readable in memory
- Your mailbox The stored copy needs your keys. Encrypted
Outgoing internet mail
- Your browser Your sent copy stays encrypted to your account keys. Sent copy encrypted
- Seige Decrypts a temporary copy in memory and delivers it over certificate-verified TLS. Readable during delivery
- Receiving provider Handles ordinary mail in readable form. Readable
Between Seige accounts
The sender's browser encrypts the message before it leaves the device. The recipient's inbox copy and the sender's sent copy are encrypted separately to their respective account keys. Each user decrypts their copy locally.
Incoming internet mail
Seige processes ordinary incoming email in memory and encrypts it to the recipient's public key before writing it to storage. The sending server receives confirmation only after the encrypted message has been saved. If that fails, it can retry delivery.
SMTP buffers use non-swappable memory. Mail services refuse to start without the required memory-storage safeguards. Ordinary internet mail is readable during transport processing; the stored mailbox copy requires the recipient's keys.
Outgoing internet mail
Seige requires certificate-verified TLS when delivering to another mail server. The delivery service uses a separate, encrypted temporary copy for retries and decrypts it in memory. The user's sent copy remains encrypted to their account keys. The receiving provider handles ordinary mail in readable form.
The live temporary copy is removed after delivery, permanent failure or expiry. If a connection ends without a confirmed outcome, Seige marks delivery as uncertain to avoid automatically sending a duplicate.
Tracking protection
Opening a message in Seige does not reveal the reader's IP address or opening time through remote images. Seige fetches supported images when ordinary incoming mail arrives, encrypts them with the message, and displays them after browser decryption. Opening the message does not request those images from the sender's server.
Identified tracking pixels are blocked. Images that fail safety, size or time limits remain blocked. Older mail and end-to-end encrypted mail display embedded images only. A sender may observe the arrival-time fetch from Seige's server.
Email HTML is sanitized and displayed in a browser sandbox. Scripts, forms and automatic navigation are disabled. Seige removes known tracking parameters from links where doing so preserves signed URLs. Clicking a link still contacts its destination.
Retention and backups
Mailbox backups contain messages encrypted to users' keys. Temporary outgoing copies and the private delivery key are excluded. The delivery key cannot decrypt the inbox or sent-folder copies.
The mail worker expires undelivered outgoing copies after two days and delivery-report tokens after seven days. Cleanup resumes with the worker after an interruption. Database history and existing infrastructure snapshots follow their own retention controls; deleting a live record does not erase every historical copy.
Message-content encryption does not cover routing addresses, delivery status, timestamps or operational logs.
Devices and application updates
Encryption depends on your device and the application running on it. Someone with control of your device or the application code delivered to your browser could capture your password, keys or readable content. Stolen keys or a guessed password can expose data without breaking the encryption algorithms.
Ada, AI requests and your private memories
Ada is your assistant inside Seige. It can use account tools to search your mail, read files, consult saved memories and work across your connected-app data. Your account's private keys stay in the browser's account worker. The language model receives the context prepared for a request, including conversation, selected memories and results returned by tools.
-
Inside Seige
Ada works across your account
Your request can use conversation, saved memory and information retrieved by account tools.
Changes require your approval -
Inside a third-party app
The app sends its own AI input
The model receives that app's prompt and supplied data. This request has no Ada tools or access to her memory.
Separate AI permission
Where Ada's memory lives
Saved conversations, memories and preferences live in encrypted account storage, shown under Ada in Storage. You can inspect them there, including the saved database and the memory and preference documents. Connecting an app to its own folder does not give it the keys to that separate storage.
Giving an app AI access also does not expose Ada's conversations, saved memories or account tools. The app sends its own prompt and input and receives the answer for that request. Any account content it sends must first have been made available to that app, such as through an approved folder or something you enter directly.
What the model sees
When Ada uses a memory or reads a file to answer you, that context is sent in readable form through Seige's AI service for model processing. Your stored copies remain encrypted. The model receives request context; it does not receive your private account keys or automatically download the full contents of your account.
Actions that change files, mail or saved memories require your approval. App data, mail and documents are treated as untrusted input. Their contents do not grant new permissions to an app or authorize an action by themselves.
Technical details of assistant isolation
Ada's conversations and memories are stored in an encrypted SQLite database in account storage. The memory and preference Markdown files are editable views of database records. The signed-in browser decrypts the relevant records and constructs model context; selected plaintext crosses the AI-processing boundary.
SDK inference requires the separate ai.generate permission. Its endpoint accepts an app prompt and input, constructs a request without tools, and checks the live grant before and during the request. It does not attach Ada's history or memory. Ada's own tool loop runs in the trusted account browser session, validates tool calls and requires approval for mutations.