Skip to main content

Encryption Protocol

Dernière mise à jour : March 12, 2026 · Pli Scellé

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

Cryptographic primitives used by Pli Scellé
FunctionAlgorithmParameters
Symmetric encryptionAES-256-GCM256-bit key, 96-bit IV, built-in authentication tag
Key derivation (passwords)PBKDF2-SHA-256600,000 iterations, random salt, 256-bit output
Key generation (files)AES-256 randomBrowser CSPRNG via Web Crypto API
Random number generationCSPRNGOperating system entropy source
Password hashing (access control)scryptServer-side, with cryptographically random salt

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).

What the server sees and doesn't see
DataServer sees?Notes
Source file / plaintext secretNoEncrypted client-side before upload
AES-256 encryption keyNoStays in URL fragment, never in HTTP request
Encrypted file (ciphertext)YesStored encrypted at rest
IV and saltYesRequired for decryption, not secret per AES-GCM spec
Access password hashYesscrypt hash, not the plaintext password

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 (Chunked Streaming)

Large files are encrypted in streaming mode using a dedicated Web Worker to avoid blocking the main thread and to minimize memory footprint.

Process

  1. A random AES-256 key is generated via Web Crypto API
  2. The file is split into fixed-size chunks for streaming encryption
  3. A random 96-bit IV is generated once per file
  4. Each chunk receives a unique derived IV to ensure no IV reuse across chunks
  5. Each chunk is encrypted independently with AES-256-GCM
  6. The encrypted output uses a versioned binary format for forward compatibility

Key Transport

The key is exported as base64url and appended to the share URL as a fragment. Since the fragment is never included in HTTP requests, the server cannot intercept the key during transport.

4. Secret Encryption (Passwords & Text)

  1. A cryptographically random salt is generated
  2. The encryption key is derived from the access password via PBKDF2-SHA-256 with 600,000 iterations
  3. The plaintext is encrypted with AES-256-GCM using a fresh random 96-bit IV
  4. The server stores only the ciphertext, IV, and salt — never the plaintext or the key

Decryption by recipient: the recipient enters the access password → the key is re-derived from password + salt → the secret is decrypted entirely client-side.

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 7 days) 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

7. Storage & Data Retention

8. Quantum Resistance

Pli Scellé's encryption relies on AES-256-GCM (symmetric) and PBKDF2-SHA-256 (key derivation). These algorithms are 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 7 days, 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