PBKDF2, ou Password-Based Key Derivation Function 2, transforme une entrée de type mot de passe et un paramètre supplémentaire nommé salt en une clé dérivée. Le résultat dépend aussi du nombre de répétitions, de la fonction utilisée et de la longueur demandée. Avec les mêmes entrées et réglages, on obtient le même résultat. BIP39 emploie précisément PBKDF2-HMAC-SHA512 ; d’autres usages peuvent retenir des paramètres différents.
Les mots de récupération constituent l’entrée appelée password. Salt est une seconde entrée : le texte littéral "mnemonic" suivi de la passphrase, un mot de passe supplémentaire facultatif. On n’intercale ni séparateur ni nouvelle copie des mots. Sans passphrase, salt reste "mnemonic" et n’est pas une chaîne vide. Les deux entrées passent par NFKD, qui uniformise certaines représentations des caractères, puis par l’encodage UTF-8. BIP39 utilise HMAC-SHA512, 2048 répétitions et une sortie de 64 octets, soit 512 bits. Cette sortie est le seed ; salt n’est pas une sauvegarde supplémentaire à créer. [1]
Le mécanisme interne utilise HMAC, un calcul qui combine une clé et un message. À chaque tour, la même entrée de mot de passe sert de clé. Le premier résultat intermédiaire utilise salt et le numéro du bloc de sortie ; les tours suivants traitent le résultat intermédiaire précédent. Les résultats sont combinés par XOR, une opération entre les bits correspondants. HMAC-SHA512 produit 64 octets, donc un seul bloc suffit pour BIP39. Appliquer uniquement SHA-512 au texte 2048 fois serait un autre calcul, avec un autre résultat. [2] [1]
Imaginez une restauration dans un autre portefeuille. Pour retrouver le même seed, il faut les mêmes données normalisées et les mêmes réglages. Augmenter les 2048 répétitions prescrites n’améliore pas la restauration : cela s’écarte de BIP39 et produit un résultat différent. Traduire les mots vers une autre liste n’est pas non plus un changement neutre. La restauration exige une correspondance, pas une adaptation personnelle de l’algorithme. [1]
Répéter le calcul augmente le coût de chaque essai, mais n’ajoute aucun hasard indépendant. Un attaquant qui connaît vos mots et dispose d’informations permettant de reconnaître le bon portefeuille peut essayer des passphrases faibles hors ligne, sur son propre ordinateur. Un seed long de 512 bits ne représente donc pas forcément 512 bits d’imprévisibilité. Le nombre 2048 n’est pas non plus une recommandation générale pour de nouveaux systèmes : il appartient ici à une norme précise de récupération. [2] [1]
Le checksum de BIP39 aide à repérer des mots mal recopiés. PBKDF2 répond à une autre question : comment calculer un seed à partir des entrées fournies ? Ce calcul ne confirme pas que la passphrase correspond à votre portefeuille d’origine. Le seed peut ensuite être traité par BIP32, une méthode de dérivation de toute une famille de clés. Vérifier la transcription, la convertir en seed et créer les clés sont des étapes liées, mais pas interchangeables. [1]
Un développeur peut comparer ses résultats à des vecteurs de test publics : des entrées connues et leurs sorties attendues. BIP39 publie les données aléatoires initiales, les mots et le seed complet pour la passphrase de test TREZOR. Une implémentation correcte doit reproduire le résultat, règles NFKD comprises. Votre véritable sauvegarde est inutile pour cet essai. N’utilisez jamais ces exemples publics pour conserver de l’argent : tout le monde les connaît. Réussir le test du calcul ne prouve pas non plus la sécurité de toute l’application. [1]
Pour une vision complète, lisez aussi BIP 39, BIP39 passphrase, Seed Generation, HD Wallet. Cette entrée est également citée par BIP39 passphrase.