Transparence E2EE — leggit

Le modèle simple

Quand vous écrivez un mot de passe ou ajoutez un fichier dans un coffre personnel, leggit applique le pattern envelope encryption : le contenu lui-même n'est chiffré qu'une seule fois, avec une clé éphémère ; cette petite clé est ensuite "emballée" (wrappée) pour chaque destinataire séparément.

1. Écriture (E2EE) : votre navigateur génère une DEK (Data Encryption Key) aléatoire de 32 octets, puis chiffre le contenu une fois avec cette DEK (XChaCha20-Poly1305 ; secretstream pour les fichiers chunkés). Tout cela s'exécute dans un Web Worker isolé.
2. Wraps multi-destinataires : pour chaque destinataire, c'est la DEK (32 octets), pas le contenu, qui est chiffrée avec leur clé publique X25519 via crypto_box_seal. On obtient donc un seul cipher de contenu + N petits "wraps" de la DEK (~80 octets chacun). Pour vous-même, votre DEK est aussi wrappée avec votre KEK (clé maître dérivée de votre mot de passe).
3. Envoi : le serveur leggit reçoit uniquement le cipher opaque du contenu et la liste des wraps de DEK. Il ne voit jamais le clair ni la DEK elle-même.
4. Lecture (E2EE aussi) : quand vous re-consultez un item, le serveur vous renvoie le cipher du contenu et votre wrap personnel (celui chiffré pour vous). Votre navigateur déballe la DEK avec votre KEK, puis déchiffre le contenu. Un destinataire procédera pareil avec sa clé privée X25519. Un badge E2EE dans la liste et la modale confirme le mode.

Pourquoi cette dichotomie ? Le chiffrement symétrique (DEK + cipher) est rapide même pour des fichiers de 100 Mo, mais une clé symétrique ne peut pas être partagée telle quelle. Le chiffrement asymétrique (X25519) sait partager une clé entre interlocuteurs sans secret commun préalable, mais il serait trop lent pour chiffrer des Mo de données. On combine donc les deux : symétrique pour le contenu, asymétrique pour la DEK.

Garantie technique : sous réserve d'intégrité du code JavaScript servi (vérifiable via les hashes SRI ci-dessous), nos administrateurs ne peuvent pas accéder à vos données tant qu'ils ne se substituent pas au navigateur.

Périmètre actuel

Pile cryptographique

• Algorithmes :
  • AEAD symétrique : XChaCha20-Poly1305-IETF (nonce 24 octets, anti-rejeu)
  • Dérivation de clé : Argon2id13 (memory-hard, anti-GPU)
  • Wraps asymétriques destinataires : X25519 + crypto_box_seal (sealed box)
  • Fichiers chunked : secretstream_xchacha20poly1305 (state-based, anti-truncation)
  • Fingerprints DEK (anti-wrap-injection serveur-side) : SHA-256 via WebCrypto API native
• Bibliothèque : libsodium-wrappers 0.7.13 servie en local depuis nos serveurs (pas de CDN externe — anti-supply-chain). Hash SRI vérifiable. Le Web Worker l'importe via importScripts en chemin relatif.
• Isolation des clés : votre KEK et votre privkey X25519 sont détenues dans un Web Worker isolé. Le main thread (DOM, scripts inline) ne peut pas y accéder directement — mitigation XSS partielle.
• Validation serveur-side anti-malicious-browser :
  • Tous les wraps d'un item doivent partager le même dek_fingerprint (sinon un attaquant qui contrôle le navigateur pourrait injecter sa propre DEK dans un wrap parasite).
  • Les id_recipient doivent appartenir à la whitelist du coffre.
  • Re-auth obligatoire (mot de passe re-saisi) pour ajouter un destinataire à un coffre déjà E2EE.

Hashes SRI des scripts critiques

Chaque script JS de la chaîne crypto est servi avec un hash SRI (Subresource Integrity). Le navigateur refuse d'exécuter le script si le hash diffère. Vous pouvez recalculer ces hashes localement et les comparer :

openssl dgst -sha384 -binary fichier.js | openssl base64 -A
# ou
shasum -a 384 fichier.js | xxd -r -p | base64

Modèle de menace — ce que l'E2EE protège

• Dump de la base de données froide — le cipher seul est inutilisable sans la clé du user.
• Insider passif (admin curieux qui lit les logs ou la BDD) — les contenus sont opaques.
• RCE instantanée qui ne modifie pas le code source (lecture de la mémoire, dump fichiers).

Modèle de menace — ce que l'E2EE NE PROTÈGE PAS

• Compromission active du code JS servi (un attaquant qui modifie nos serveurs et sert un JS malicieux). Mitigé par : SRI, CSP stricte, sub-resource versioning, audit du déploiement — mais pas éliminé.
• Navigateur de l'utilisateur compromis (malware local, extension malicieuse). Hors de notre contrôle.
• Contrainte juridique forcée de modifier le code serveur (cas rare, lawfare).

Vos données — comment les exercer (RGPD)

En mode E2EE, leggit ne peut techniquement pas répondre à un droit d'accès classique : nous n'avons pas accès à vos données.

Le droit d'accès s'exerce via un export self-service depuis votre compte : votre navigateur récupère tous vos coffres + items + fichiers, déchiffre via le Worker, et produit un fichier ZIP local que vous téléchargez. Le serveur ne voit que des blobs chiffrés transiter.

Accéder à mon compte / export RGPD →

Engagements long terme

• Publication des hashes SRI à chaque déploiement.
• Pentest externe annuel sur la chaîne crypto (en cours d'organisation).
• Roadmap : extension navigateur officielle et client desktop signé pour éliminer la dépendance au JS servi par nos serveurs.