Aller au contenu
Vault

Sécurité

Ce que DYCAST voit, et surtout ce qu’il ne voit pas

Votre secret est chiffré dans votre navigateur avant de partir. Le serveur ne garde qu’un bloc indéchiffrable, qu’il efface dès la lecture.

Le chemin d’un secret

  1. Votre navigateur tire au hasard une clé de 256 bits et la place après le # du lien. Cette partie d’une adresse n’est jamais transmise au serveur par les navigateurs.
  2. Le secret (et l’éventuel identifiant, l’adresse, la note) est chiffré en AES-256-GCM sous une clé dérivée de celle-ci (HKDF-SHA-256), après bourrage par paliers de 512 octets : la taille du chiffré ne révèle pas la longueur du mot de passe.
  3. Avec l’option mot de passe, la clé dépend aussi de ce mot de passe, étiré par Argon2id (64 Mio, 3 passes) : il faut le lien et le mot de passe.
  4. Le serveur ne remet le chiffré qu’à qui présente une preuve dérivée de la clé, et compte la lecture dans la même opération : à la dernière lecture autorisée, le chiffré est effacé, les pages de la base qui le contenaient sont écrasées et le journal de la base est vidé. Deux ouvertures simultanées d’un secret à lecture unique ne peuvent pas réussir toutes les deux.
  5. Pour un secret à mot de passe, seul un essai qui présente le bon lien compte pour le blocage anti-essais : quelqu’un qui ne connaît que l’adresse sans la clé ne peut pas en priver votre destinataire.
  6. Ouvrir le lien n’affiche rien tant que vous n’avez pas cliqué sur « Afficher » : les robots qui inspectent les liens (messageries, antispam) ne consomment pas la lecture.

Identifiants complets : le lien seul ne suffit pas

Un lien voyage souvent par e-mail. Si la boîte de votre destinataire est piratée, l’intrus a le lien. Pour un simple mot de passe isolé, c’est le risque assumé d’un lien à usage unique (et vous êtes prévenu s’il est lu). Mais dès qu’il y a une adresse ou un identifiant et un mot de passe, le site exige davantage, et vérifie votre adresse :

  • Lien + code de déverrouillage : un code de 12 caractères, à transmettre par SMS ou téléphone, entre dans la clé (Argon2id). L’intrus qui a le lien n’a que la moitié de la clé ; chacun de ses essais vous est signalé par e-mail, et l’accès se bloque après 10 codes faux.
  • Remise en main propre : le lien ne contient aucune clé de déchiffrement. L’appareil du destinataire crée sa propre clé X-Wing (ML-KEM-768 + X25519) et affiche un code à 6 chiffres. Vous êtes prévenu, vous l’appelez, vous saisissez ce code : le secret est alors chiffré pour cet appareil seulement. Un intrus qui ouvrirait le lien obtiendrait un autre code, et ne recevrait rien. Le code est tiré du lien, que le serveur ne connaît pas : même un serveur compromis ne pourrait pas en fabriquer un identique. L’autorisation se fait depuis le navigateur qui a créé le secret, où la clé du secret est gardée sous une clé d’appareil que rien ne peut extraire.

Et votre propre boîte mail ? Nous n’y envoyons jamais ni le lien ni le secret : seulement des avis (« votre secret a été lu », « un code faux a été saisi », « une demande d’ouverture attend »). Un intrus qui la lirait apprendrait qu’un secret existe, sans pouvoir l’ouvrir ni autoriser quoi que ce soit.

Post-quantique, concrètement

  • Demandes de secret : la clé publique du demandeur est une clé X-Wing, qui combine ML-KEM-768 (standard NIST FIPS 203, résistant au quantique) et X25519 (éprouvé). Il faudrait casser les deux pour lire une réponse. L’empreinte de cette clé est dans le lien envoyé au correspondant : un serveur malveillant ne pourrait pas la remplacer. Chaque réponse est en outre authentifiée par une clé tirée de ce lien, inconnue du serveur : il ne pourrait pas non plus fabriquer une fausse réponse.
  • Remise en main propre : la clé du secret est chiffrée pour la clé X-Wing de l’appareil du destinataire, combinée à une clé tirée du lien.
  • Partage par lien (et lien + code) : aucune clé publique n’intervient. Tout repose sur des clés symétriques de 256 bits et SHA-256, que l’algorithme quantique de Grover ne fait que ramener à 128 bits de sécurité.
  • Transport : la connexion passe par Cloudflare, qui négocie l’échange de clés hybride X25519MLKEM768 avec les navigateurs récents.

Ce que le serveur connaît

  • l’adresse e-mail vérifiée de qui partage, les dates, le nombre de lectures autorisées et effectuées ;
  • la taille arrondie du chiffré (par paliers de 512 octets) ;
  • une empreinte de la preuve d’accès. Les adresses IP ne sont gardées que sous forme d’empreinte, pour les plafonds anti-abus.

Il ne connaît ni la clé, ni le secret, ni l’identifiant, ni la note. Les données ne sont ni répliquées ni sauvegardées : un secret détruit l’est pour de bon.

Le site lui-même

  • Aucun script, police ou image tiers, politique de sécurité de contenu stricte (Trusted Types, aucun script en ligne, aucun cadre), bibliothèques cryptographiques auditées noble figées et vérifiées, API WebCrypto du navigateur.
  • HSTS, aucun référent transmis, cookie de session __Host-, accès réservé au réseau Cloudflare.

Ce que le chiffrement ne fait pas

Quiconque obtient le lien complet avant votre destinataire peut lire le secret : c’est pourquoi vous êtes prévenu à la lecture, et pourquoi un secret lu par quelqu’un d’autre doit être changé aussitôt. Pour un accès sensible, ajoutez un mot de passe transmis par un autre canal.

La page retire la clé de la barre d’adresse dès qu’elle l’a lue, mais l’historique de votre navigateur (et sa synchronisation) peut garder l’adresse visitée : sur un poste partagé, utilisez la navigation privée. Le lien d’un secret n’est conservé ni par nos serveurs ni sur votre appareil ; seuls les liens de boîte des demandes le sont, sur l’appareil qui les a créés, et ils sont effacés à la déconnexion.

Enfin, ce site sert lui-même le code qui chiffre : le chiffrement protège vos secrets contre une fuite de nos bases ou un accès à nos disques, pas contre un serveur que l’on aurait modifié pour servir un autre code. Un appareil compromis reste, lui aussi, hors de portée de toute cryptographie.