Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

La solution retenue 9af2 Décidé

Chiffrement convergent à clé, avec un secret par tenant. Pour démarrer, « ton tenant » = toi seul.

Un secret maître par tenant, dérivé d’une passphrase via Argon2id, qui ne quitte jamais le client. Puis, pour chaque chunk :

# secret maître, jamais transmis secret = Argon2id(passphrase, sel) # par chunk — tout est déterministe clé_chunk = BLAKE3_keyed(secret, chunk) chiffré = XChaCha20-Poly1305(clé_chunk, chunk) adresse = BLAKE3(chiffré)

Deux machines de ta flotte qui voient le même chunk dérivent la même clé → même chiffré → même adresse → dédup. Un autre tenant a un secret différent → tout diffère, ni dédup ni oracle entre vous. L’opérateur, qui détient blobs et index mais pas le secret, ne peut pas calculer l’adresse d’un fichier candidat : il perd l’attaque par confirmation.

Deux précisions qui comptent Nonce déterministe sur les chunks. La convergence impose un chiffré identique pour un clair identique. Comme la clé est unique par contenu, un nonce fixe est sûr — le choix de l'AEAD (XChaCha20 plutôt qu'AES-GCM-SIV) est détaillé au point aead.
Métadonnées — régime différencié Répertoires et racines de snapshots : jamais convergents. Ils portent les noms, la structure et les dates — très identifiants, très devinables, et de dédup négligeable (les mtimes diffèrent toujours entre machines) : nonce aléatoire sous une clé du tenant. Les manifestes de fichier, eux, sont convergents : purs contenus (ni nom ni date), impossibles à deviner sans posséder le fichier entier — auquel cas l'oracle des chunks suffit déjà. Les rendre convergents n'ajoute aucune surface d'attaque et offre la dédup des recettes entre machines. Détail et justification au point dag.

Chemin simple : v1 = un seul tenant (toi). La crypto est exactement la même ; passer au multi-tenant plus tard se fait en provisionnant d’autres secrets, sans refonte.

Ce qui fuit encore, pour être honnête : l’opérateur reste aveugle au contenu et à la confirmation, mais pas aux tailles ni au timing des blobs (analyse de trafic). Résidu classique, qu’on réduit par du padding le jour où ça entre dans le modèle de menace.

Les paramètres Argon2id — le hachoir volontairement lent

En clair — pourquoi ralentir exprès Une passphrase humaine est devinable : dictionnaires, variations, fuites. Or en mode managé, la plateforme stocke la CMK emballée sous une clé dérivée de la passphrase : qui vole ce blob peut essayer des milliards de passphrases hors ligne, sur ses GPU, sans être vu. La seule défense : rendre chaque essai coûteux. Argon2id est un hachoir à trois réglages — la mémoire (le hachoir exige un plan de travail immense : des centaines de Mo — c'est la défense anti-GPU, car une carte graphique a des milliers de petites lames mais de minuscules plans de travail), le temps (le nombre de passages), le parallélisme (combien de bras tournent la manivelle). L'asymétrie magique : le légitime paie une fois (1-2 s au déverrouillage, imperceptible) ; l'attaquant paie à chaque essai × des milliards × privé de ses GPU = des siècles. Et le sel rend chaque serrure unique — aucun dictionnaire précalculé ne sert deux fois.

Les décisions — et la subtilité qui compte :

  • Les paramètres voyagent avec le sel. Ils ne sont pas secrets (il les faut pour re-dériver) : ils sont enregistrés dans l'enveloppe, à côté du sel. Chaque déverrouillage lit « m=512 Mio, t=4, p=4 » et applique. Conséquence : aucun paramètre global figé — pas de rigidité, pas de migration de format.
  • Calibrage à l'enrôlement. La machine benchmarke : combien de mémoire et de passes pour atteindre ~1-2 s ici ? Un desktop moderne montera à 512 Mio–1 Gio ; un NAS à 512 Mio de RAM totale descendra vers le plancher en compensant par plus de passes.
  • Les planchers, sourcés RFC 9106 — premier choix recommandé : m=2 Gio, t=1, p=4 ; environnement contraint en mémoire : m=64 Mio, t=3, p=4. 64 Mio est notre plancher absolu (profil NAS) : en dessous, on refuse de dériver.
  • Mise à niveau opportuniste. Chaque changement de passphrase = une re-dérivation = un re-calibrage gratuit vers le haut. La rotation de KEK et la montée en force du KDF sont la même opération.