Recuperação de backup SLIP39: o que ter partes suficientes não comprova

Financiamento: o CypherpunkGuide pode receber comissões de indicação por meio dos guias de compra vinculados. Este artigo não contém links diretos de compra com afiliação. Nenhum fornecedor de carteira patrocinou o experimento.

SLIP39 é um padrão que permite representar o backup de um segredo em partes compostas por palavras. A passphrase é uma sequência secreta adicional, separada dessas partes, que pode ser necessária para recuperar a carteira desejada.

Restaram dois cartões de um backup dividido em três. Num esquema de 2 de 3, isso pode bastar. Ainda é preciso saber se os cartões pertencem ao mesmo conjunto, se outro grupo é necessário e se a carteira pretendida exige uma passphrase.

Em 6 de outubro de 2026, executei 45 vetores de teste oficiais, ou seja, entradas com resultados esperados conhecidos, e mais 32 verificações com dados fictícios públicos. Os 77 casos produziram o resultado previsto. Esse total inclui recusas esperadas e dois casos que retornaram um valor diferente sem avisar que a passphrase estava errada. Não foram 77 recuperações bem-sucedidas de carteiras.

O experimento usa a implementação de referência do SLIP39, um programa que implementa o padrão. Não testa um dispositivo físico, não localiza bitcoin nem assina transações. Para distinguir recebimento, assinatura e recuperação do acesso, comece pelas verificações de autocustódia.

Conte os grupos completos, além dos cartões

#

Um backup SLIP39 pode exigir um número mínimo de partes dentro de cada grupo e um número mínimo de grupos completos. Cada parte codificada do backup, normalmente registrada como palavras, é uma share. O limiar é a quantidade exigida em cada nível.

A especificação SLIP39 define essa organização em dois níveis. Nosso backup de teste exigia dois de três grupos. Cada um dos dois primeiros grupos precisava de duas das suas três shares; o último tinha uma única share e se completava com ela. Dois cartões do primeiro grupo completavam apenas um grupo. Não atendiam à condição do backup inteiro.

As 15 combinações mínimas válidas desse backup recuperaram o valor esperado. Os dois exemplos incompletos foram recusados. Em outro backup de teste, com uma configuração simples de 2 de 3, cada um dos três pares possíveis funcionou. Fornecer a mesma share duas vezes não criou uma segunda share distinta.

Essas partes reconstroem um único segredo. Não são chaves de assinatura independentes, como numa carteira Bitcoin multisig convencional. O experimento de recuperação multisig trata desse outro problema. Nenhum dos métodos é automaticamente a melhor opção para qualquer pessoa.

Shares corretas não confirmam a passphrase

#

O SLIP39 não verifica se a passphrase digitada é aquela que você pretendia usar. Nos dois testes com passphrase deliberadamente incorreta, a reconstrução a partir das shares e a descriptografia terminaram, mas os dados recuperados eram diferentes do valor público esperado.

Primeiro, o programa reconstruiu o segredo mestre criptografado, ou EMS: o valor criptografado representado pelas shares. Depois, usou a passphrase para obter o resultado sem criptografia. A documentação do firmware da Trezor também separa a reconstrução a partir das shares da derivação que depende da passphrase.

Uma mensagem de conclusão precisa ser interpretada com esse limite. No experimento, terminar o processamento não bastava. Só conseguimos identificar a divergência porque já conhecíamos o valor fictício original. Não derivamos endereços nem consultamos saldos. Uma carteira vazia após uma recuperação real exige investigação; este resultado, sozinho, não identifica a causa.

O programa não serve para descobrir passphrases. O artigo sobre recuperação de senhas aborda outro tipo de problema.

Um backup novo pode manter o anterior utilizável

#

Criar outro backup do mesmo segredo pode deixar os materiais anteriores válidos para recuperação. No teste, recuperamos o mesmo valor esperado com um backup anterior de uma única share, um backup anterior de 2 de 3 e um novo backup de 2 de 3.

“Anterior” indica apenas a ordem em que os criamos no experimento. Os três usaram o formato extensível e o mesmo identificador, 42. Não testamos um formato antigo do SLIP39 nem o procedimento de atualização de um dispositivo.

Separadamente, o guia de atualização da Trezor informa que criar um backup adicional para uma carteira existente compatível não invalida o original. A interface e as condições de compatibilidade dependem do produto. Nosso exemplo matemático não testa essas condições.

Para cuidar da privacidade e do controle de acesso, inclua os backups anteriores no inventário, além do mais recente. Criar mais shares não equivale a invalidar material que já vazou. Este artigo não orienta você a destruir backups, redefinir dispositivos ou transferir fundos.

O que as 77 verificações demonstraram

#

Os testes distinguem três resultados: o valor corresponde ao esperado, o valor é diferente ou o programa recusa a entrada. O arquivo de resultados por caso preserva as 77 observações.

As duas últimas linhas exigem cuidado. Reutilizamos de propósito os metadados, as informações que descrevem o conjunto, para gerar as mesmas palavras iniciais em divisões independentes. Aquela mistura foi recusada numa verificação de consistência. Um único caso não estabelece a frequência de falhas nem o comportamento de todas as misturas possíveis. Palavras iniciais iguais não comprovam a identidade da carteira.

A recusa de shares excedentes é uma condição da função de recuperação dessa implementação. Ela exige uma seleção com a quantidade exata do limiar. Isso não significa que ter as três shares impeça a recuperação: cada par já havia passado no teste.

O pacote para reproduzir o experimento contém a implementação oficial numa versão fixa, as entradas e os resultados. Os valores são públicos e o gerador de números de teste repete sempre a mesma sequência, permitindo reproduzir os resultados. Nunca use essas shares para guardar fundos nem adapte o programa para receber suas palavras de recuperação reais. O README do projeto avisa expressamente que a implementação não recebeu as proteções necessárias para lidar com segredos sensíveis. Executá-la offline não a transforma numa ferramenta segura para recuperações reais.

Conferimos os vetores oficiais comparando os bytes do segredo mestre recuperado com os valores esperados. As chaves privadas estendidas BIP32 incluídas nesses vetores não foram testadas. Compatibilidade entre dispositivos, busca de endereços, assinatura e procedimentos de recuperação executados por pessoas ficaram fora do experimento.

Confira o plano sem reunir os segredos

#

Um inventário de recuperação deve registrar quais condições foram conferidas, sem reunir as palavras de recuperação. O formulário em branco tem campos de status, não espaços para shares, passphrases, nomes de pessoas ou endereços dos locais de armazenamento.

Confira o formato do backup e a compatibilidade de recuperação documentada, as shares e os grupos necessários, a necessidade de uma passphrase separada e a validade dos backups anteriores. Considere também se um único incidente poderia atingir vários locais de armazenamento. Mantenha o inventário privado quando seu conteúdo puder revelar como você organiza a segurança.

Use o procedimento de conferência documentado pelo fornecedor para o produto em questão. Não apague materiais válidos para preencher o formulário. Um teste de restauração de arquivos pode confirmar que os arquivos armazenados são legíveis; não comprova que eles atendem às condições de recuperação de uma carteira específica.

Pontos principais

#

Perguntas sobre os resultados

#

Posso combinar cartões porque as primeiras palavras são iguais?

#

Palavras iniciais iguais permitem apenas uma conferência preliminar dos metadados. Elas não substituem a validação completa das shares, a reconstrução bem-sucedida nem a conferência das condições da carteira pretendida. Nossa mistura com as mesmas palavras iniciais passou pela decodificação, mas foi recusada na verificação de consistência da recuperação.

A recusa de três shares significa que devo descartar uma?

#

Não. Ela descreve uma exigência de entrada da função de recuperação testada. As três combinações de duas shares funcionaram. Isso não justifica descartar material de recuperação nem presumir que a interface de um dispositivo se comporte da mesma forma.

Este experimento comprova que tenho um plano de herança?

#

Não. Ele confere dados públicos de teste numa única implementação. Não estabelece quem consegue encontrar e usar os materiais, quem tem autoridade legal nem se o processo continuará funcionando após a morte do titular.

Fontes e cópias arquivadas

#

A cópia arquivada do repositório sustenta o aviso sobre segredos sensíveis. Ela não é uma cópia do commit exato usado no experimento. Essa versão e os hashes de seus arquivos estão incluídos no pacote de reprodução.