Comment partager un secret sans risquer une fuite

Avouons-le : échanger des informations sensibles sur le net, c'est galère. Tu envoies un mot de passe par email, puis tudelete dans l'urgence. Tu passes par un service tiers, en priant pour qu'ils ne lisent pas tes données. Tu l'envoies sur Slack, en sachant que ta boîte garde tout en archive ad vitam.

Il existe forcément une meilleure solution.

Et devine quoi : tu peux la construire directement dans ton navigateur.

Le problème avec les services de partage de secrets

Des outils comme OneTimeSecret ont popularisé l'idée des liens à destruction automatique. Tu colles ton secret, tu récupères un lien à usage unique, tu le partages, et hop — disparu après lecture.

Mais il y a un détail que peu de gens considers : que fait concrètement ton données ?

Même avec des services "temporaires", ton secret en clair transite souvent par leurs serveurs. Ils promettent de ne pas le lire. Ils promettent de le supprimer. Mais pourquoi faire confiance à des promesses quand on peut rendre ça impossible ?

C'est là que le chiffrement de bout en bout (E2EE) change tout. Avec un vrai E2EE, le serveur ne peut pas lire ton secret. Il ne stocke que du ciphertext — des bytes aléatoires inutiles sans la clé. Le serveur devient une simple boîte de stockage, pas un gardien de tes secrets.

Comment ça fonctionne concrètement

Imaginons que Bob veuille partager un mot de passe de base de données avec Alice. Le truc élégant : le chiffrement se fait entièrement dans le navigateur de Bob, avant même que quoi que ce soit n'atteigne le serveur.

Le processus :

1. Bob saisit son secret et choisit une passphrase
2. Son navigateur dérive une clé cryptographique à partir de cette passphrase
3. Le secret est chiffré localement avec cette clé
4. Bob envoie à Alice un lien (contenant le ciphertext et le salt) plus la passphrase (par un canal séparé)

Pourquoi deux canaux séparés ? Si le lien et la passphrase voyagent ensemble et que quelqu'un intercepte le lien, il a tout. Envoie le lien par Slack et la passphrase par Signal. Ou SMS. Ou pigeon voyageur. L'important : deux surfaces d'attaque distinctes.

Alice reçoit le lien, entre la passphrase dans son navigateur qui redérive la clé localement, et le secret se déchiffre — tout ça sans que le serveur ne voie jamais de données lisibles.

La cryptographie derrière tout ça

Là ça devient technique, mais accroche-toi — c'est élégant.

Dérivation de clé : PBKDF2

Les humains sont catastrophiques pour générer des clés aléatoires à haute entropie. On tape "motdepasse123" et on se sent créatifs. Donc on a besoin d'une fonction qui transforme des passphrases faibles en clés cryptographiques solides — lentement, volontairement.

PBKDF2 (Password-Based Key Derivation Function 2) fait exactement ça. Elle prend ta passphrase, ajoute un salt aléatoire (stocké publiquement), et fait tourner 600 000 itérations de hachage SHA-256. Chaque tentative dans une attaque par force brute coûte du temps CPU. À 600k itérations, craquer une passphrase médiocre devient computationally infaisable.

async function deriveKey(passphrase, salt) {
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    "PBKDF2",
    false,
    ["deriveKey"]
  );
  
  return crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: salt,
      iterations: 600_000,
      hash: "SHA-256"
    },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

Chiffrement symétrique : AES-GCM

Pour le chiffrement proprement dit, on utilise AES-256-GCM. Ce n'est pas le AES dont tu as peut-être entendu parler dans des contextes théoriques — c'est la version authentifiée. Le mode GCM ne se contente pas de chiffrer tes données : il génère aussi un tag d'authentification. Si quelqu'un modifie le ciphertext en transit, le déchiffrement échoue avec une erreur au lieu de produire silencieusement des données corrompues.

Il nécessite aussi un vecteur d'initialisation (IV) unique pour chaque chiffrement. Pense au salt : public, aléatoire, essentiel pour la sécurité. AES-GCM, c'est du costaud — c'est ce que la NSA recommande pour les informations classifiées.

async function encrypt(plaintext, key) {
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const encoded = new TextEncoder().encode(plaintext);
  
  const ciphertext = await crypto.subtle.encrypt(
    { name: "AES-GCM", iv: iv },
    key,
    encoded
  );
  
  return { iv, ciphertext };
}

Pourquoi zéro dépendance compte

Cette approche est radicale : pas de npm packages. Pas de bibliothèques crypto. Pas de confiance dans du code tiers.

Tu utilises ce qui existe déjà dans ton navigateur. Web Crypto API est standardisé depuis 2015 et disponible dans tous les navigateurs modernes. C'est backed par les vendors de la plateforme — Apple, Google, Microsoft, Mozilla — qui ont investi massivement dans des implémentations correctes et en temps constant.

Pense à la surface d'attaque des applications typiques qui accumulent les dépendances. Log4Shell, c'est arrivé à cause d'une dépendance. Le incident left-pad a cassé une partie d'Internet à cause d'une dépendance. Chaque npm install est une décision de confiance.

Avec Web Crypto API, tu fais confiance à l'implémentation native du navigateur. C'est une surface d'attaque bien plus réduite que de faire confiance à un package npm random avec 2 millions de téléchargements hebdomadaires.

Côté serveur : du stockage bêta, c'est suffisant

Backend-side, tu stockes :

• Le ciphertext (inutile sans la clé)
• Le salt (pas secret, nécessaire pour la dérivation de clé)
• L'IV (pas secret, nécessaire pour le déchiffrement)
• Des métadonnées (date de création, expiration, nombre de vues)

Configure ton Redis (ou Valkey) avec save "" et appendonly no — donc aucune persistance. Quand le processus meurt, tout s'évapore. Configure correctement le swap pour éviter que des données touchent le disque.

Le serveur devient un blob store temporaire chiffré. Il enforce les règles d'accès (une seule vue, expiration) mais ne peut pas lire le contenu, même s'il le voulait.

Ce que ça signifie pour ton stack

Tu peux embarquer ça directement dans n'importe quelle web application. Un champ de formulaire ici, quelques fonctions JavaScript là, et soudain ton app a le partage de secrets éphémère sécurisé intégré. Pas de changement backend nécessaire — ton serveur se contente de stocker et servir des blobs chiffrés.

C'est particulièrement puissant pour :

• Les outils internes qui doivent partager des credentials temporairement
• Les systèmes de support client qui transfèrent des données sensibles
• Les workflows developer qui partagent des clés API ou des mots de passe de base de données

Les secrets sont cryptographiquement isolés de ton infrastructure. Même si quelqu'un compromet ta base de données, il obtient du ciphertext impossible à craquer sans la passphrase.

Les compromis en valent la peine

Est-ce que PBKDF2 avec 600k itérations est plus lent qu'Argon2 ? Oui. Argon2, le standard moderne pour le hachage de mots de passe, n'est pas encore disponible dans Web Crypto API. Mais considère le contexte : ce sont des secrets à usage unique, généralement consultés dans les minutes qui suivent. Le coût computationnel est acceptable.

Le compromis — KDF légèrement moins robuste pour zéro dépendance — en vaut la peine pour la plupart des cas d'usage. Tu ne protèges pas des codes de lancement nucléaire. Tu partages un mot de passe de base de données qui sera de toute façon changé demain.

Construis-le, ne fais pas confiance

La beauté de l'E2EE, c'est que tu n'as pas besoin de faire confiance à l'opérateur du service. Tu peux auditer le code. Tu peux l'auto-héberger. Tu peux vérifier que le serveur ne voit vraiment jamais de plaintext.

Dans un monde où les data breaches font la une chaque jour, construire des systèmes où le serveur est cryptographiquement aveugle n'est pas juste malin — c'est responsable.

Donc la prochaine fois que tu dois partager un secret en ligne, rappelle-toi : la meilleure façon de protéger des données, c'est de ne jamais les laisser quitter les mains de l'utilisateur non chiffrées. Et avec Web Crypto API, tu as les outils pour que ça se passe comme ça, directement dans le navigateur.

Prêt à implémenter ? Web Crypto API est disponible dans tous les navigateurs modernes. Pas d'installation, pas d'étape de build, pas de dépendances — juste de la cryptographie native au navigateur qui attend d'être utilisée.