Le principe
Votre secret est chiffré dans votre navigateur avec une clé aléatoire de 256 bits. Cette clé est placée dans le lien, après le signe #. Les navigateurs n'envoient jamais cette partie de l'adresse : nos serveurs ne reçoivent qu'un bloc chiffré, qu'ils ne peuvent pas déchiffrer. Même avec un accès complet à nos serveurs et à notre base, personne ne lit un secret sans le lien complet.
Anatomie d'un lien
https://eclair.kayzen-lyon.com/s/35fZoy72KMhzS86v9fUxog#v1.p.8BJ3ft…/s/{id}: Identifiant aléatoire de 128 bits, envoyé au serveur pour retrouver le chiffré.#v1: Version du format.n ou p: Sans ou avec code PIN.{clé}: Clé de 256 bits. Jamais envoyée, jamais journalisée.
Primitives cryptographiques
| Usage | Construction | Implémentation |
|---|---|---|
| Contenu | AES-256-GCM, IV aléatoire de 96 bits, données associées liées à l'identifiant du secret | WebCrypto |
| Dérivation | HKDF-SHA-256, chaînes de contexte préfixées « eclair v1 » | WebCrypto |
| Code PIN | Argon2id (64 Mio, 3 passes) puis HKDF ; vérificateur HMAC-SHA-256 dérivé de la clé du lien | hash-wasm |
| Longueur | Contenu complété par paliers (1, 4, 16, 64 Kio…) pour masquer sa taille réelle | — |
Pourquoi le serveur ne peut pas tester vos codes PIN
Le vérificateur envoyé au serveur est calculé à partir du code ET de la clé du lien. Sans la clé, le serveur ne peut ni vérifier un code ni en essayer. Il se contente de compter les erreurs et détruit le secret au cinquième essai.
Ce contre quoi nous protégeons
- Fuite de notre base ou de l'hébergeur : Elle ne contient que des blocs chiffrés et quelques dates.
- Robots d'aperçu (Slack, Teams, Outlook) : La page du lien ne contient pas le secret ; il n'est délivré qu'après un clic, par une requête POST.
- Deux ouvertures simultanées : La lecture et la suppression se font en une seule opération atomique, testée avec 100 lectures concurrentes.
- Énumération des liens : 128 bits aléatoires, limitation de débit, réponse identique pour un lien inconnu, expiré ou déjà lu.
- Script piégé : Aucun script tiers, politique de sécurité du contenu stricte avec nonces, dépendances épinglées et auditées.
Les limites, en toute honnêteté
- Un attaquant qui détient à la fois le lien et une copie de notre base peut tester hors ligne les codes PIN courts. Pour un secret critique, choisissez une phrase de passe.
- Le chiffrement dans une page web suppose que le code servi par notre site soit intègre. L'extension et les applications signées, en préparation, réduiront ce risque.
- Nous voyons des métadonnées : dates, palier de taille, nombre de lectures.
- Un destinataire peut toujours recopier le secret après l'avoir lu.
- Le service n'a pas encore été audité par un tiers. L'audit est prévu avant la version 1.0 et son rapport sera publié.
Vérifier par vous-même
Voir la requête envoyée au serveur
Signaler une vulnérabilité
Écrivez-nous en suivant notre fichier security.txt. Nous ne poursuivrons jamais une personne qui signale de bonne foi une faille. security.txt · contact@kayzen-lyon.fr