Cas d’usage
Chiffré de bout en bout
Chiffrez dans le navigateur avec une phrase secrète. Votre serveur et votre bucket stockent des octets qu’ils ne peuvent pas lire.
const key = await deriveKey(passphrase, salt) // PBKDF2 or Argon2, in the browser
const iv = crypto.getRandomValues(new Uint8Array(12))
const ciphertext = await crypto.subtle.encrypt({ name: 'AES-GCM', iv }, key, encoded)
// The transfer holds the salt, the IV and the ciphertext. Nothing else.
await transfers.createSnapshot({
data: { salt: toBase64(salt), iv: toBase64(iv), ciphertext: toBase64(ciphertext) },
version: 3,
})La situation
Ce qui se passe vraiment.
Le problème
Par défaut, votre serveur peut lire chaque transfert qu’il stocke. Pour un journal, un gestionnaire de mots de passe, des données de santé ou un contrat, c’est le mauvais défaut, et une responsabilité que vous ne voulez peut-être pas porter.
Ce que s3nd y fait
s3nd stocke ce que vous lui donnez. Dérivez une clé d’une phrase secrète avec WebCrypto, chiffrez la charge utile dans le navigateur, et envoyez le texte chiffré. Le bucket, votre serveur et quiconque devine le code voient des octets inutilisables ; la phrase secrète voyage avec la personne, pas sur le fil. Ça marche pareil pour un fichier que pour un snapshot.
À surveiller
Les choses faciles à rater.
La compression vient après le chiffrement
Le texte chiffré ne se compresse pas. Attendez-vous à une taille stockée égale à la taille brute, et réglez maxSize en conséquence.
Deux secrets, deux canaux
Le code passe par un canal et la phrase secrète par un autre, ou dans la tête de la personne. Un code seul ne vaut plus rien pour qui le devine.
Une phrase secrète perdue, ce sont des données perdues
C’est ce que « de bout en bout » veut dire. Dites-le dans l’interface avant que l’utilisateur ne s’y fie.
Voir aussi
D’autres formes de la même primitive.
Déposez un fichier. Donnez le code.
Pointez-le sur le bucket que vous payez déjà. Rien à déployer, aucune inscription, personne au milieu.