How Zero-Knowledge End-to-End Encryption Works on Ilusion

Standard communication channels like Slack, Teams, and email store messages in plain text or decrypt them on their servers. If a server is compromised or an account is breached, your shared database credentials, API keys, and environment variables are exposed. Ilusion solves this by using zero-knowledge end-to-end encryption (E2EE), meaning only you and the recipient hold the key to read the data.

When you generate a sharing link on Ilusion, the entire cryptographic flow occurs inside your web browser: 1. Local Key Generation: The browser uses the standard Web Cryptography API to generate a high-entropy 256-bit symmetric encryption key in temporary memory. 2. Local AES-256 Encryption: The plaintext secret is encrypted locally on your machine using the AES-GCM (Galois/Counter Mode) authenticated encryption algorithm. 3. Securing the Key in the URL: The symmetric key is appended to your generated link as a URL hash fragment (e.g., /secret/[id]#[decryption_key]). 4. Zero-Knowledge Upload: Only the encrypted ciphertext is sent to Ilusion's database. By web specification (RFC 3986), anything after the hash symbol (#) remains in the browser and is never transmitted to the server. Hence, Ilusion has zero knowledge of your encryption key.

When the recipient visits the link, their browser performs the decryption locally: 1. The recipient's browser fetches the encrypted ciphertext from Ilusion's database. 2. The browser extracts the decryption key from the URL hash fragment (#[decryption_key]) locally in memory. 3. The browser decrypts the payload using the WebCrypto API. The plain text never touches Ilusion's servers. 4. Instantly upon successful decryption, the server triggers an auto-purge operation, deleting the encrypted payload and any associated files from S3. We do not use soft-deletes, backups, or logs.

Yes. It is critical to understand that using a Custom URL Alias or an Inbox Drop halts browser-only zero-knowledge end-to-end encryption. How this works: To support clean, branded URLs (e.g. /s/acme-setup with no messy hash fragment at the end), the browser cannot keep the key hidden locally. Because web servers must handle the redirect routing, the symmetric decryption key is sent to the server and stored securely in our database under the dropKey field. While your data is still fully encrypted in transit via TLS/HTTPS and stored securely at rest, our server technically holds the key for redirection. If your workflow requires absolute, non-negotiable zero-knowledge E2EE (where no server ever holds the decryption key under any circumstance), you must use standard links (which retain the hash fragment) rather than custom aliases.