Encryption Protocol

This document describes the end-to-end encryption (E2E) protocol implemented by Pli Scellé. All cryptographic operations use the W3C Web Crypto API - no external cryptographic library is used.

1. Cryptographic Primitives

2. Zero-Knowledge Architecture

In E2E mode, the server never has access to the encryption key or plaintext content. The key is generated client-side and transmitted exclusively via the URL fragment (#key=...), which is never sent to the server by the browser (RFC 3986 §3.5).

Consequence: even with full database and storage access, an attacker cannot decrypt E2E shares without the key held exclusively by the sender and recipient.

3. File Encryption

Files are encrypted in the browser before upload. A random AES-256 key is generated per file via the Web Crypto API, and the content is encrypted with AES-256-GCM. The key is exported as a base64url fragment in the share URL. Because the fragment is never included in HTTP requests, the server never receives it.

4. Secret Encryption (Passwords & Text)

1. A random AES-256 key is generated in the browser via the Web Crypto API, as for files
2. The plaintext is encrypted with AES-256-GCM using a fresh random 96-bit IV
3. The key is placed in the fragment of the share URL, never sent to the server
4. The server stores only the ciphertext and the IV, never the plaintext or the key

Decryption by recipient: the browser reads the key from the URL fragment, fetches the ciphertext and decrypts the secret entirely client-side.

Access password: it does not encrypt anything. It is a server-side access control: the server keeps only an argon2id hash of it and releases the ciphertext only once the password is verified.

5. Share Lifecycle

1. Creation: the sender encrypts content in the browser, uploads the ciphertext, receives a unique URL with the key in the fragment
2. Sharing: the URL is transmitted out-of-band (email, messaging, etc.)
3. Access: the recipient opens the URL → the browser extracts the key from the fragment → downloads the ciphertext → decrypts locally
4. Expiration: after the configured duration (1 hour to 30 days, depending on the plan) or maximum view count, the share is permanently purged - ciphertext deleted from storage, metadata erased from database
5. Revocation: the sender can destroy a share at any time from their dashboard

6. Transport Security

• TLS 1.2+ mandatory on all client-server communications (HSTS preload)
• Access tokens: cryptographically random, generated server-side with high entropy
• Download tokens: short-lived ephemeral tokens, verified via timing-safe comparison to prevent timing attacks
• Rate limiting: throttling on all public endpoints to mitigate brute-force and abuse

7. Storage & Data Retention

• At rest: in E2E mode the server holds only ciphertext it cannot decrypt. Non-E2E text secrets are encrypted server-side; the plaintext is never stored.
• Automatic purge: expired shares are permanently deleted (ciphertext and metadata), with no recovery possible.
• Antivirus: from the Essential plan, unencrypted files are scanned by ClamAV after they are uploaded, and anonymous uploads are scanned on every plan. By default, a share that contains an archive or a file over 25 MiB is not scanned at all. End-to-end encrypted content is never scannable, since the server only holds ciphertext.
• Hosting: France exclusively. No file or share data leaves the European Union. Only billing data may be transferred by Stripe to the United States, under standard contractual clauses.

8. Quantum Resistance

Pli Scellé's encryption relies on AES-256-GCM (symmetric), with a random 256-bit key. This algorithm is considered resistant to quantum attacks: Grover's algorithm reduces the effective security of AES-256 to ~AES-128, a level still considered secure by NIST and ANSSI.

The current sharing flow does not use asymmetric key exchange (RSA, ECDH) - the algorithms vulnerable to quantum attacks are not present in the protocol.

For future features requiring asymmetric exchange, the architecture is designed to integrate ML-KEM (Kyber, FIPS 203) in hybrid mode (classical + post-quantum) when browser standards (Web Crypto API) and audited libraries become available.

Shares on Pli Scellé are ephemeral (expiration from 1 hour to 30 days depending on the plan, automatic purge). The "store now, decrypt later" scenario - where an attacker captures ciphertext today and decrypts it in 10-20 years with a quantum computer - does not apply to ephemeral data that no longer exists.

9. Transparency & Security Posture

• Non-E2E mode: shares created without E2E use server-side encryption. The server can decrypt these shares. E2E mode is recommended for maximum confidentiality.
• Browser trust model: as with all web-based E2E encryption, security depends on the integrity of the code delivered to the browser. We mitigate this risk with strict Content Security Policy headers on share pages and regular security assessments.
• URL fragment handling: while the fragment is not transmitted to the server, it may appear in browser history or be shared inadvertently. We recommend using password-protected shares for sensitive content.