Seed Generation

Imagine escolher palavras de um livro favorito para memorizar facilmente o backup. Elas podem parecer incomuns para você, mas um invasor pode testar justamente citações e padrões humanos conhecidos. Por isso, BIP39 começa com aleatoriedade gerada por computador e só depois a representa em palavras. A entropia descreve sua imprevisibilidade. As palavras são um registro legível de dados secretos, não um convite para inventar uma frase. [1]

A carteira precisa realmente obter dados aleatórios, não apenas chamar uma função com o nome certo. Linux oferece, por exemplo, getrandom(), que por padrão espera a fonte do sistema ficar pronta. Com GRND_NONBLOCK, pode retornar EAGAIN em vez de esperar: os dados ainda não estão disponíveis. O programa deve verificar o resultado e o número de bytes, as unidades de dados recebidas. Continuar após uma falha como se a entrada secreta tivesse sido criada pode produzir uma carteira aparentemente funcional, mas insegura. [2]

Navegadores também oferecem uma interface para dados aleatórios seguros. Web Crypto getRandomValues() preenche um array de inteiros com bytes criptograficamente seguros; solicitações acima de 65536 bytes falham com QuotaExceededError. Isso descreve uma função, não comprova a segurança do site inteiro. Uma página pode obter boa aleatoriedade e depois vazar as palavras de backup. Também é preciso examinar o código carregado e o que ele faz com o resultado. [3]

Se você copiar uma palavra incorretamente, a carteira pode detectar o erro com um checksum: uma verificação curta calculada a partir dos dados originais. BIP39 acrescenta 4 bits de controle a 128 bits de entrada para formar 12 palavras; 256 bits com 8 bits de controle formam 24 palavras. O bit é uma unidade básica de informação. Os bits de controle vêm de uma impressão digital dos dados calculada por SHA256, não de entropia independente adicional. Um checksum válido não prova que as palavras sejam secretas ou tenham sido geradas com segurança. [1]

As palavras facilitam o backup; o software precisa convertê-las em dados precisamente definidos. BIP39 usa a função de derivação PBKDF2-HMAC-SHA512 com 2048 repetições para produzir um seed de 512 bits. Além da frase, usa um parâmetro chamado salt: aqui, o texto literal mnemonic seguido da passphrase, ou de uma sequência vazia se ela não for usada. A frase e esse parâmetro são processados em UTF-8 NFKD, que padroniza a representação dos caracteres. Uma saída mais longa não cria a aleatoriedade que falta: seu comprimento não prova 512 bits de entropia de entrada. [1]

BIP32 descreve a próxima etapa. Deriva uma chave privada mestra e um chain code, dados auxiliares usados para derivar outras chaves. Assim, a carteira pode criar novos endereços a partir de uma origem comum. Tecnicamente, aplica HMAC-SHA512 com o texto fixo Bitcoin seed como chave dessa função e divide o resultado. Esse texto público não é o seu segredo. Uma chave privada derivada igual a zero ou fora do intervalo permitido é inválida. Portanto, o seed não é simplesmente renomeado como chave privada. [4]

Desenvolvedores precisam saber se o programa faz os cálculos corretamente. Os vetores de teste fornecem entradas conhecidas e resultados esperados. BIP39 publica conjuntos com entropia, palavras e seed, incluindo a passphrase de teste TREZOR. Obter o resultado esperado verifica a conversão daquela entrada; não prova que o gerador real produza segredos imprevisíveis. Como os dados de teste são públicos, nunca devem servir como backup secreto de fundos reais. [1]

Várias etapas conectam a fonte de aleatoriedade, as palavras e o armazenamento do backup. NIST SP 800-90C descreve como combinar fontes de entropia com mecanismos de geração de dados aleatórios. Avaliar uma carteira exige também examinar a versão específica do software, o tratamento de erros e a passagem de dados entre etapas. Um componente bem verificado não garante que outro não perca ou divulgue o segredo. O objetivo é acompanhar o processo inteiro, não procurar um único nome que transmita confiança. [5]