Your data,
unreadable even to us.

leggit applies modern end-to-end encryption standards. Here is, in plain words, how it works — and why it protects you.

The principle: zero-knowledge

"Zero-knowledge" literally means: leggit has no knowledge of the contents of your vaults. Your data is encrypted on your device before being sent, and the key that decrypts it never leaves your machine, nor that of your recipients.

Practically, even if our servers were seized or compromised, the contents would remain unreadable — an encrypted file without its key is just random noise.

Since the platform's E2EE (end-to-end encryption) evolution, this principle is no longer a promise: it is a verifiable technical guarantee. For your personal vaults, encryption and decryption happen inside your browser, within an isolated Web Worker that alone holds your keys. The leggit server only ever receives opaque encrypted blobs.

Envelope encryption

Each item (text, file, message) is encrypted with a unique random key called the Data Encryption Key (DEK). That DEK is itself encrypted with your master key, derived from your password using Argon2id (a costly algorithm that resists massive attacks).

Benefit: when you change your password, only the DEKs are re-encrypted, not all your files.

X25519 public keys for recipients

Each recipient has a public/private keypair generated on their own device. To transmit data to Alice, your vault encrypts the DEK with Alice's public key: only Alice's private key can decrypt it.

X25519 is the algorithm used by WireGuard, Signal, and all modern encrypted messaging solutions.

Shamir Secret Sharing

For account recovery or post-mortem release, leggit splits a critical key into several mathematically linked pieces. For instance into 5 pieces, of which 3 are required to reconstruct the secret.

No single piece reveals any information: the quorum must be reached — for example 3 trustees out of 5 — to trigger decryption. No one can act alone.

AEAD: integrity and confidentiality

All encryption uses AEAD algorithms (XChaCha20-Poly1305). This means an attacker can neither read the contents nor stealthily modify a single byte of the file without detection at decryption.

Where are the keys stored?

• Your master key is derived from your password at every login via Argon2id. It is then handed directly to an isolated Web Worker in your browser, where it stays in RAM for the duration of your session. It is never persisted in plaintext, and the main JavaScript thread (DOM, inline scripts) cannot access it — limiting the impact of any potential XSS.
• Your recipients' X25519 private keys are encrypted with their own password and stored in their account.
• Shamir shares are held by the trustees you have appointed, never accessible to leggit in plaintext.
• On logout or tab close, the Worker is terminated: all in-memory keys are wiped (memzero) immediately.

Verify for yourself

You don't have to take our word for it: the browser-side cryptographic chain is designed to be auditable.

• Open your browser's developer tools (F12) → Network tab. When you write or read an item, you'll see base64 blobs (cipher_blob_b64, my_wrap) transit the wire — never plaintext.
• Check our E2EE transparency page: it exposes in real time the SRI hashes of every crypto script with the command to recompute them locally.
• Inspect the source of the scripts (right-click → "View page source"). Everything is readable, un-obfuscated, and identical to the code we publish publicly.

Our threat model is documented honestly on the transparency page — including what E2EE does not protect against (compromise of your own browser by local malware, for instance).

Current E2EE scope

Not everything is in pure browser E2EE yet — here is the real state of coverage today:

• ✅ Personal vaults (texts, passwords, files and videos up to 100 MB): full browser E2EE. Writing, reading, adding a recipient (with re-authentication), progressive migration of legacy items, and RGPD export: all flow through your browser. The server only ever sees opaque cipher blobs.
• 🔘 Family vaults (shared among multiple members): server-side encryption with multi-key sharing (Shamir + X25519 per member). The server has access to the content during active sessions to enable member-to-member sharing. Browser E2EE upgrade is on our roadmap.
• 🔘 Crypto-wallets (substitution table images): server-side libsodium secretstream encryption. E2EE upgrade planned.
• ⚙️ Post-mortem programmed messages by email: legitimately server-side. The server MUST be able to decrypt on release day to send the email to the recipient — a pure E2EE email would be undeliverable.
• ⚙️ Post-mortem release pipeline (heritage): Shamir combination + session-side decryption after quorum. For personal vaults created in E2EE, the final decryption happens in the recipient's browser.

Public roadmap: official browser extension and signed desktop client to eliminate the dependency on JavaScript served by our own servers (removing the residual "actively compromised JS" risk). Work in progress.

Audit and transparency

Every cryptographic operation is logged with a timestamp. You can review your vault's access history at any time: who saw what, when, and from where. For E2EE personal vaults, sensitive details (titles, previews) are themselves encrypted with your master key inside the log — only you can read them back via your browser.

Password recovery without leggit

If you forget your password, you cannot use a classic "click here to reset" link: leggit has no access to your master key. At sign-up, you appointed at least 2 recovery trustees.

When you forget your password, your trustees receive a notification, validate the request, and a cryptographic mechanism called Shamir Secret Sharing then reconstructs a key that lets you set a new password. leggit learns nothing during the process.

Two-factor authentication (2FA)

On top of your password, you can enable a second layer of protection: a 6-digit code generated by a standard authentication app (Google Authenticator, Authy, 1Password) on your phone.

With 2FA active, even if someone knows your password (through phishing, a leak or shoulder-surfing), they cannot sign in without your phone. Strongly recommended for vaults containing crypto wallets or highly sensitive data.

Court order / legal requisition

leggit may receive a legal requisition from a magistrate or a State authority. What can we hand over? Only what leggit holds: encrypted blobs, metadata, login history, account identity. Not the content in clear, because we never have it.

No technical "back door" is in place to enable decryption on demand. The cryptography is mathematically airtight. If a court demands content, it must go through the recipients or the trustees, who remain free to cooperate or not.

Service continuity

What happens if leggit shuts down? We commit to three points:

• Minimum 6-month notice before effective cessation of activity.
• A full export of every vault delivered to each user, in an open and readable format (plain text + files).
• Transmission of the source code, technical documentation and encrypted databases to a designated trustee, with an escrow mechanism so that a successor can, if possible, take over.

GDPR compliance

leggit complies with the General Data Protection Regulation (GDPR) and the French Data Protection Act. You always have the right to access your data, correct it, export it, and erase it permanently.

For post-mortem transmission, leggit operates within the framework of the 2016 French Digital Republic Act (art. 84-86 of the Civil Code), which authorizes the expression and execution of digital directives after death. The post-mortem mandate signed via DocuSeal carries probative legal value.