SLIP-39

Pour sauvegarder un portefeuille BIP 32, le secret maître est sa graine d’entrée, pas sa racine privée étendue. On crée d’abord l’encrypted master secret (EMS), puis ses parts. Les calculs utilisent GF(256), octet par octet ; la spécification stocke le secret en f(255) et, pour un seuil d’au moins 2, une empreinte de vérification en f(254). [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [BIP 32 — Hierarchical Deterministic Wallets]

Il faut d’abord atteindre le seuil de membres de chaque groupe nécessaire, puis celui des groupes. Exemple : 2 groupes sur 3, chacun exigeant 2 membres sur 3. Deux parts de A et deux de B suffisent ; trois de A et une de B ne suffisent pas, bien qu’elles soient aussi quatre. Un schéma simple 2-sur-3 utilise un seul groupe. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]

La liste contient 1024 mots anglais et ne suit pas la traduction de l’interface. Un secret de 128 bits produit des parts de 20 mots, un secret de 256 bits de 33 mots. Une part contient aussi identifiant, indicateur extendable, exposant d’itérations, index et seuils. La combinaison vérifie les métadonnées communes et l’unicité des index de membres ; deux copies d’une part ne sont pas deux membres. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]

Les trois derniers mots constituent RS1024, qui détecte avec certitude les erreurs touchant au plus trois mots. Ils ne prouvent ni provenance ni autorisation du détenteur ; la spécification déconseille la correction automatique. Une empreinte de reconstruction aide à détecter un ensemble incorrect. Ce contrôle de 32 bits interdit d’appliquer sans nuance à SLIP-39 l’affirmation idéale d’absence totale de fuite sous le seuil. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]

Le chiffrement utilise quatre tours Feistel avec PBKDF2-HMAC-SHA256, chacun effectuant 2500×2^e itérations. La spécification accepte ASCII imprimable 32–126 et emploie une chaîne vide sans passphrase. La bonne passphrase ne se vérifie pas directement : une autre donne un autre secret maître. Des parts valides ne confirment donc pas le portefeuille attendu ; vérifiez ses adresses connues. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes]

BIP 39 utilise une autre liste, somme de contrôle et conversion de phrase en graine. Répartir ses mots sur des papiers ne crée ni SLIP-39 ni sa protection à seuil. Garder le même portefeuille lors d’une migration exigerait de conserver la bonne graine BIP 32 et le contexte de dérivation ; recoder l’entropie initiale avec d’autres mots ne le garantit pas. Vérifiez la procédure effectivement prise en charge. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [BIP 39 — Mnemonic code for generating deterministic keys]

L’indicateur extendable à 1 omet l’identifiant du sel de chiffrement. Le même EMS peut ainsi être repartagé avec un nouvel identifiant sans connaître la passphrase. Trezor décrit l’extension d’une sauvegarde compatible à une part vers plusieurs parts. Le nouvel ensemble n’invalide pas l’ancien : une combinaison initiale suffisante permet toujours de retrouver le même secret. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [Trezor — Multi-share Backup]

SLIP-39 reconstitue un secret lors de la restauration ; il ne crée ni Multisig ni approbation on-chain de chaque transaction. La répartition doit limiter les pertes communes et l’acquisition d’une combinaison suffisante par un attaquant. Testez la restauration sur un appareil fiable, conservez passphrase et contexte du portefeuille, puis vérifiez la compatibilité avec l’implémentation de référence et les vecteurs de test. Le nombre de parts ne suffit pas. [SLIP-0039 — Shamir Secret-Sharing for Mnemonic Codes] [Trezor — python-shamir-mnemonic reference implementation]