Sécurité

Le Principe Fondamental

Vos données ne quittent jamais votre appareil. Chaque outil de Privacy First Labs traite les données entièrement dans votre navigateur en utilisant les Web APIs standard. Aucun fichier n'est téléchargé vers nos serveurs. Aucun texte en clair n'est transmis. Aucun traitement côté serveur n'a lieu.

Ce n'est pas une politique — c'est une garantie architecturale. Nos outils sont des pages statiques servies par Cloudflare Pages. Il n'y a pas de serveur d'application, pas de base de données et aucun point d'accès API qui accepte vos données. Vous pouvez le vérifier vous-même en ouvrant l'onglet réseau de votre navigateur pendant l'utilisation de n'importe quel outil.

Chiffrement de SafeSeal

SafeSeal vous permet de chiffrer des secrets (mots de passe, clés API, identifiants) avec un mot de passe et de les partager sous forme de lien ou de fichier. Voici exactement comment cela fonctionne.

Algorithme de Chiffrement

Nous utilisons AES-256-GCM (Advanced Encryption Standard avec des clés de 256 bits en Galois/Counter Mode) via la Web Crypto API native du navigateur. C'est le même standard de chiffrement utilisé par les gouvernements, les banques et les applications de sécurité critique dans le monde entier.

• AES-256 assure la confidentialité — votre secret est illisible sans la clé
• GCM mode assure l'authentification — toute altération des données chiffrées est détectée et rejetée
• La Web Crypto API est une implémentation native du navigateur, pas une bibliothèque JavaScript tierce qui pourrait être compromise

Dérivation de Clé

Votre mot de passe n'est jamais utilisé directement comme clé de chiffrement. Au lieu de cela, nous dérivons une clé cryptographique à partir de celui-ci en utilisant PBKDF2 (Password-Based Key Derivation Function 2) :

• Fonction de hachage : SHA-256
• Itérations : 600 000 — le minimum recommandé par l'OWASP (2023) pour SHA-256
• Salt : 16 octets de données cryptographiquement aléatoires, uniques par chiffrement
• Résultat : Une clé AES de 256 bits

Le nombre élevé d'itérations signifie que même si un attaquant obtient les données chiffrées, le forçage par essais du mot de passe est extrêmement coûteux en calcul. Le salt aléatoire garantit que des mots de passe identiques produisent des clés différentes.

Processus de Chiffrement

Lorsque vous cliquez sur « Chiffrer », les opérations suivantes se déroulent entièrement dans votre navigateur :

1. Un salt aléatoire de 16 octets est généré avec crypto.getRandomValues()
2. Un vecteur d'initialisation (IV) aléatoire de 12 octets est généré avec crypto.getRandomValues()
3. Votre mot de passe + le salt sont traités par PBKDF2 (600 000 itérations) pour produire une clé AES de 256 bits
4. Votre secret est chiffré avec AES-256-GCM en utilisant la clé dérivée et l'IV
5. Le résultat inclut une étiquette d'authentification de 16 octets (vérification d'intégrité de GCM)

Le salt et l'IV sont tous deux générés aléatoirement à chaque chiffrement. Cela signifie que chiffrer le même secret avec le même mot de passe deux fois produit un texte chiffré complètement différent.

Mode Lien

En mode lien, les données chiffrées sont encodées dans le fragment de l'URL (la partie après #) :

privacyfirstlabs.io/safeseal/#1.<salt>.<iv>.<ciphertext>

Le fragment de l'URL n'est jamais envoyé à un serveur. Ce n'est pas un choix de notre part — c'est le fonctionnement du protocole HTTP. Selon la RFC 3986 (Section 3.5), l'identifiant de fragment est traité entièrement par le client. Lorsque vous ouvrez le lien, votre navigateur demande /safeseal/ à notre serveur — la partie #... reste dans votre navigateur.

Les composants sont encodés en base64url (RFC 4648, Section 5) pour une inclusion sûre dans les URLs.

Mode Fichier

En mode fichier, les données chiffrées sont empaquetées dans un fichier binaire compact .pflenc :

• Octet 0 : version du format (actuellement 1)
• Octets 1–16 : salt
• Octets 17–28 : IV
• Octets 29+ : texte chiffré (incluant l'étiquette d'authentification GCM)

Avant le chiffrement, le nom du fichier original est intégré dans le payload à l'aide d'un en-tête compact : un préfixe de longueur de 2 octets suivi du nom de fichier en UTF-8, suivi des données du fichier. Cela signifie que le nom de fichier original est toujours récupéré lors du déchiffrement — le destinataire reçoit le fichier avec son nom et son extension d'origine.

Le fichier est généré entièrement dans votre navigateur et téléchargé sur votre appareil. Il n'est jamais envoyé ni stocké sur nos serveurs. Vous partagez le fichier par le canal de votre choix.

Confidentialité du Nom de Fichier

Par défaut, les fichiers chiffrés sont téléchargés sous le nom originalname.pflenc — ce qui facilite l'identification du fichier. Si vous préférez ne pas révéler le nom du fichier, l'option « Masquer le nom du fichier » télécharge le fichier sous le nom secret.pflenc.

Le nom du fichier original est toujours chiffré à l'intérieur du payload .pflenc, indépendamment de ce réglage. Lors du déchiffrement, le destinataire récupère toujours le nom du fichier original à partir des données chiffrées. La case « Masquer le nom du fichier » contrôle uniquement le nom du fichier .pflenc externe lors du téléchargement — elle n'affecte pas le contenu chiffré.

Processus de Déchiffrement

Lorsque le destinataire ouvre le lien ou télécharge le fichier .pflenc :

1. Le salt, l'IV et le texte chiffré sont extraits du fragment de l'URL ou du fichier
2. Le destinataire saisit le mot de passe
3. PBKDF2 dérive la même clé AES à partir du mot de passe + salt (600 000 itérations)
4. AES-256-GCM déchiffre le texte chiffré et vérifie l'étiquette d'authentification
5. Si le mot de passe est incorrect ou les données ont été altérées, le déchiffrement échoue avec une erreur générique

Le message d'erreur ne révèle intentionnellement pas quelle vérification a échoué (mot de passe incorrect vs. données corrompues). Cela empêche les attaquants d'utiliser les différences d'erreurs pour obtenir des informations sur le chiffrement.

Ce Que Notre Serveur Voit

Pour SafeSeal — rien. Notre serveur délivre des fichiers statiques HTML, CSS et JavaScript. Il ne reçoit, ne traite ni ne stocke :

• Votre texte secret
• Votre mot de passe de chiffrement
• Les données chiffrées
• La clé de déchiffrement
• Aucun fragment d'URL (techniquement impossible — les navigateurs n'envoient pas les fragments aux serveurs)

Même si nos serveurs étaient compromis, un attaquant n'obtiendrait que les fichiers statiques du site — jamais vos données chiffrées ou vos clés.

Ce Que Nous Ne Pouvons Pas Faire

En raison de notre architecture à connaissance zéro :

• Nous ne pouvons pas déchiffrer vos secrets — nous n'avons jamais les clés
• Nous ne pouvons pas récupérer votre mot de passe — il n'existe que sur votre appareil et celui du destinataire
• Nous ne pouvons pas répondre aux demandes de production de texte en clair — nous ne l'avons pas
• Nous ne pouvons pas savoir si un lien a été utilisé ou combien de fois — nous n'avons aucun suivi

C'est intentionnel. La responsabilité de la gestion des clés vous incombe, à vous et à votre destinataire. Si le mot de passe est perdu, le secret est irrécupérable.

Vérifiez Par Vous-même

Vous n'avez pas à nous croire sur parole. Voici comment vérifier nos affirmations :

• Onglet réseau : Ouvrez les Outils de Développement de votre navigateur (F12), allez dans l'onglet Réseau et utilisez SafeSeal. Vous verrez zéro requête réseau contenant votre secret ou vos données chiffrées
• Code source : Notre module de chiffrement est conçu pour une publication open-source. La logique centrale utilise uniquement la Web Crypto API native du navigateur — aucune bibliothèque cryptographique tierce
• Test hors ligne : Déconnectez-vous d'internet, puis chiffrez et déchiffrez un secret. Cela fonctionne — parce que rien ne quitte jamais votre navigateur

Isolation du Traitement

Toutes les opérations intensives en calcul (dérivation de clé, chiffrement, déchiffrement) s'exécutent dans des Web Workers — des threads d'arrière-plan isolés qui :

• Maintiennent l'interface réactive pendant l'exécution des 600 000 itérations de PBKDF2
• N'ont aucun accès au DOM ni au contexte JavaScript principal de la page
• Sont créés par opération et terminés immédiatement après leur achèvement
• Ne conservent aucune donnée entre les opérations

Considérations de Sécurité

Robustesse du Mot de Passe

La sécurité de votre secret chiffré dépend de votre mot de passe. Nous exigeons un minimum de 8 caractères, mais nous recommandons fortement l'utilisation d'une phrase de passe plus longue. PBKDF2 avec 600 000 itérations offre une protection significative contre les attaques par force brute, mais un mot de passe faible (comme « password123 ») peut toujours être deviné.

Partage de Liens

En mode lien, les données chiffrées sont dans l'URL. Toute personne ayant accès à l'URL complète dispose des données chiffrées (bien qu'elle ait toujours besoin du mot de passe pour les déchiffrer). Partagez les liens via des canaux sécurisés et partagez toujours le mot de passe par un canal différent de celui du lien.

Sécurité du Navigateur

Le chiffrement côté client dépend d'un environnement de navigateur sécurisé. Si votre navigateur ou votre appareil est compromis (malware, extensions malveillantes), les garanties de chiffrement peuvent ne pas être maintenues. Maintenez votre navigateur et votre système d'exploitation à jour.

Pas de Forward Secrecy

Si un attaquant capture le lien ou le fichier chiffré et obtient ultérieurement le mot de passe, il peut déchiffrer le secret. Pour les cas d'utilisation très sensibles, envisagez de changer régulièrement les mots de passe et d'utiliser des méthodes de partage à durée limitée.

Résumé Technique

Des questions ?

Si vous avez des questions sur notre implémentation de chiffrement, avez trouvé une vulnérabilité potentielle ou souhaitez discuter de notre architecture de sécurité :

Privacy First Labs
security@privacyfirstlabs.io

Nous accueillons la divulgation responsable et nous nous engageons à traiter les problèmes de sécurité rapidement.