Modèle de sécurité

Modèle de menace

Zone de confiance

Votre navigateur

Crypto

Chiffrement

Hachage

Dérivation de clé

Données utilisateur

Les données restent locales

Entrée : texte, mots de passe, fichiers

Mots de passe

Fichiers

Zone externe

Serveur

Aucun accès à ce que vous saisissez, collez ou téléchargez

Réseau

Vos saisies ne sont pas transmises

Tiers

Aucun partage de données

Hypothèses de sécurité

• Votre appareil est sécurisé
• Navigateur moderne avec API Web Crypto
• Mots de passe robustes

Limites

• Un appareil compromis = un risque
• Les extensions de navigateur disposant de permissions étendues peuvent accéder au contenu de la page
• Nous ne pouvons pas récupérer les mots de passe perdus – le chiffrement est mathématiquement irréversible

Propriétés de sécurité et limites explicites de notre architecture côté client.

Hypothèses de confiance

Appareil exempt de logiciels malveillants
Navigateur standard et à jour
Aucune extension compromise
Réseau sécurisé (HTTPS)
Compréhension des limites de la cryptographie

Limites explicites

Ne protège pas contre les menaces locales telles que les keyloggers, les moniteurs de presse-papiers ou les logiciels d'enregistrement d'écran.
Ne peut pas empêcher le partage accidentel d'une sortie sensible (par exemple, copier un jeton chiffré dans une application de chat non fiable).
Suppose une utilisation correcte des paramètres cryptographiques. La sécurité du chiffrement AES-GCM, par exemple, repose sur un mot de passe fort et unique fourni par l'utilisateur.
Ne fournit pas d'authentification – toute personne disposant du mot de passe peut déchiffrer les données.
Ne protège pas contre les attaques par rejeu si les données chiffrées sont interceptées et re-soumises.

Cycle de vie de la clé et format du conteneur

Cette section documente les paramètres réellement utilisés par l'outil. Ils proviennent de ENCRYPT_CONFIG dans le dépôt : une modification y change à la fois l'interface, le worker et l'en-tête du conteneur.

Dérivation de clé : PBKDF2-HMAC-SHA-256, 100 000 itérations, clé de 32 octets. Un sel de 16 octets est généré à chaque chiffrement avec crypto.getRandomValues().
Chiffrement : AES-256-GCM avec un IV de 12 octets et une étiquette d'authentification de 16 octets. La clé dérivée reste dans le worker du navigateur et n'est jamais enregistrée.
Sortie texte : base64 ou hexadécimal du sel, de l'IV et du chiffré. Le sel et l'IV sont aussi affichés séparément, pour déchiffrer sans deviner les paramètres.
Sortie fichier : en-tête ZVE1 de 40 octets (magic, version, nombre d'itérations, sel, taille de bloc de 1 Mio, nombre de blocs, taille totale), puis pour chaque bloc un IV de 12 octets et le chiffré avec sa propre étiquette.
L'index du bloc est lié comme AAD : un bloc réordonné ou remplacé est rejeté par GCM au lieu de renvoyer un clair erroné.

Compatibilité et limites

Les fichiers produits avant ce conteneur (sel | IV | chiffré+étiquette, sans magic) sont toujours déchiffrés automatiquement.
Limites : 50 Mo par fichier, 16 Mio par bloc, 1 048 576 blocs. Les entrées plus volumineuses sont refusées avant tout appel cryptographique.
Rien n'est conservé : fermer l'onglet efface la clé dérivée du mot de passe ; seul le cache du service worker pour la coque de l'application subsiste (voir la note de stockage).