Este texto nasceu de uma pergunta simples: qual é a entropia usada pelo LND (Lightning Network Daemon) para gerar suas chaves e como ela se compara ao problema divulgado recentemente na Coldcard?
A resposta curta é tranquilizadora para quem usa LND: o aezeed trabalha com 128 bits de entropia obtidos do gerador criptográfico do sistema operacional.
O caso da Coldcard foi diferente. Em determinadas versões do firmware, uma falha de integração fez a geração da seed passar por um gerador previsível, reduzindo drasticamente o espaço que um atacante precisaria pesquisar.
Mas a parte mais interessante está no caminho até essa resposta. O incidente mostra por que não basta contar palavras, olhar o tamanho de uma chave ou encontrar “SHA-256” na documentação.
A segurança começa antes: na origem da aleatoriedade.
As 24 palavras não contam toda a história
Quando uma carteira apresenta 24 palavras, é natural associá-las a uma seed de 256 bits. Muitas carteiras BIP39 realmente funcionam assim.
Só que as palavras são uma forma de representar dados. Elas não garantem, sozinhas, que todos esses dados tenham sido produzidos de maneira imprevisível.
Pense em um gerador que tenha apenas 2³² resultados possíveis. São cerca de 4,3 bilhões de combinações.
Se cada resultado passar por SHA-256, a saída terá 256 bits e parecerá completamente aleatória. Ainda assim, o universo original continuará limitado aos mesmos 4,3 bilhões de candidatos.
O hash embaralha. Não inventa aleatoriedade nova.
É por isso que uma sequência longa pode carregar pouca entropia. O que importa não é apenas o tamanho do resultado, mas quantas possibilidades independentes existiam antes de ele ser produzido.
Com 128 bits de entropia, temos 2¹²⁸ possibilidades. Não é apenas o dobro de 64 bits. Cada bit adicional duplica o espaço de busca, fazendo a diferença crescer de forma exponencial.
Onde a Coldcard errou
A Coldcard deveria usar um gerador aleatório de hardware na criação da seed. O componente existia e o código destinado a acessá-lo também.
O problema estava na ligação entre as partes.
Durante uma mudança no firmware, a geração passou de ckcc.rng_bytes() para ngu.random.bytes(). Essa segunda chamada acabou resolvida para um gerador pseudoaleatório do MicroPython, chamado Yasmarang, e não para o gerador de hardware pretendido.
O detalhe parece pequeno. Na prática, muda tudo.
Esse gerador era inicializado com elementos como o identificador do microcontrolador, contadores internos, horário e temporização da inicialização.
São valores que podem variar, mas não devem ser tratados automaticamente como segredos criptográficos. Dependendo do conhecimento do atacante sobre o dispositivo e sua inicialização, o conjunto de resultados pode ser reproduzido ou bastante reduzido.
A análise técnica da Coinkite estimou um espaço de busca efetivo de aproximadamente 40 bits nos modelos Mk2 e Mk3 afetados.
Para Mk4, Q e Mk5, a estimativa apresentada foi de aproximadamente 72 bits, graças à contribuição adicional dos secure elements.
A equipe de segurança da Block fez uma leitura mais conservadora. Segundo sua análise, os modelos mais recentes recebiam dados dos secure elements, mas apenas quatro bytes chegavam à função de reseed. Em termos estritamente criptográficos, isso limita essa contribuição a 32 bits.
Os números de 32 e 72 bits parecem contraditórios, mas estão medindo coisas diferentes.
A estimativa mais ampla inclui estados e temporizações que o atacante talvez não conheça. A análise de 32 bits pergunta quantos bits realmente secretos e aleatórios foram inseridos no reseed.
Incerteza para o atacante pode aumentar o custo de um ataque. Isso não significa que toda essa incerteza tenha a mesma qualidade de uma fonte criptográfica de entropia.
Essa distinção é importante para não simplificar demais o caso — tanto para minimizar o problema quanto para transformá-lo em pânico.
E como o LND faz isso?
O LND não usa BIP39 para sua seed padrão. Ele utiliza o aezeed, um formato próprio com 24 palavras.
Dentro dele estão um byte de versão, dois bytes que registram a data aproximada de criação da carteira, 16 bytes de entropia e os dados necessários para criptografia, salt e verificação de integridade.
Os 16 bytes são o ponto central da comparação:
16 bytes × 8 = 128 bits de entropia
Isso também explica por que não devemos olhar para as 24 palavras do aezeed e concluir que existem 256 bits independentes de aleatoriedade.
As palavras codificam mais coisas além da entropia. O número correto, no caso do LND, é 128 bits.
Na criação normal da carteira, o código do aezeed solicita esses bytes ao crypto/rand.Reader da linguagem Go.
Essa interface usa o gerador criptograficamente seguro oferecido pelo sistema operacional — por exemplo, getrandom() no Linux moderno.
O fluxo é direto:
Gerador criptográfico do sistema operacional
16 bytes aleatórios
128 bits de entropia
Raiz da carteira HD
O código não comprime esses 128 bits em um estado de 32 bits e não substitui a fonte criptográfica por horário, identificadores ou timers.
Se não conseguir obter a aleatoriedade necessária, a criação retorna um erro.
Colocando os números em perspectiva
Os valores de 40 e 72 bits são estimativas publicadas pela Coinkite. A Block calcula que apenas 32 bits criptograficamente secretos chegavam ao reseed dos modelos mais recentes afetados. As análises observam aspectos diferentes do problema.
Na comparação direta, o aezeed do LND utiliza 128 bits de entropia.
Uma Coldcard corrigida pode utilizar 128 bits em uma seed BIP39 de 12 palavras ou 256 bits em uma seed de 24 palavras.
Para as Coldcards afetadas, a Coinkite estimou aproximadamente 40 bits nos modelos Mk2 e Mk3 e aproximadamente 72 bits nos modelos Mk4, Q e Mk5.
A Block acrescenta a ressalva de que apenas 32 bits criptograficamente secretos alcançavam o reseed dos modelos mais recentes.
Uma seed de 128 bits possui 2⁵⁶ vezes mais combinações que uma de 72 bits. Em relação a 40 bits, a diferença é de 2⁸⁸.
Esses fatores não podem ser convertidos diretamente em horas ou anos sem conhecer o custo de testar cada candidato. Ainda assim, mostram por que 40, 72 e 128 bits não pertencem à mesma categoria de segurança.
Também vale uma observação: uma seed com 256 bits de entropia não oferece necessariamente 256 bits de resistência contra todos os ataques.
As chaves do Bitcoin usam secp256k1, cuja segurança prática contra os melhores ataques genéricos conhecidos é estimada em aproximadamente 128 bits.
Por isso, os 128 bits do aezeed estão alinhados ao nível de segurança esperado do sistema criptográfico.
Uma atualização não conserta uma seed antiga
A Coinkite lançou firmwares corrigidos para os modelos afetados. A correção resolve a geração de novas seeds, mas não muda as que já existem.
Isso merece destaque porque é fácil imaginar que atualizar o dispositivo seja suficiente. Não é.
Se a seed nasceu com pouca entropia, continuar usando as mesmas palavras em um firmware novo, em outra carteira ou depois de aplicar mais hashes não amplia seu espaço original.
A orientação da fabricante é atualizar o firmware, gerar uma seed completamente nova, conferir o fingerprint e um endereço, fazer uma transação de teste e então migrar os fundos.
A Coinkite aponta uma exceção para seeds que receberam ao menos 50 lançamentos de dados independentes, privados e corretamente adicionados durante a criação.
Uma passphrase BIP39 forte também pode oferecer uma barreira adicional, mas não transforma a seed original em uma seed bem gerada. Por isso, a recomendação continua sendo migrar quando houver dúvida.
Nada disso significa que BIP39 ou hardware wallets sejam, por definição, inseguros.
A vulnerabilidade estava em versões específicas de uma implementação. Uma Coldcard corrigida, gerando uma seed nova pelo caminho correto, volta a trabalhar no nível de segurança esperado.
O que isso significa para quem usa LND?
Para quem criou a carteira pelo processo normal do LND, não há indicação de que o incidente da Coldcard afete o aezeed.
São formatos diferentes, implementações diferentes e fontes de aleatoriedade independentes.
A vulnerabilidade divulgada não é motivo, por si só, para trocar a seed do LND ou movimentar seus fundos.
A ressalva seria uma instalação personalizada que forneceu manualmente a entropia por alguma integração externa. Nesse cenário, é preciso avaliar a origem utilizada. Isso não corresponde ao procedimento comum de criação da carteira.
Em outras palavras: a comparação serve para entender por que o caminho do LND é sólido, e não para criar uma nova preocupação para seus usuários.
Conhecer para verificar, não para temer
O caso da Coldcard reforça uma frase repetida com frequência no Bitcoin: don’t trust, verify.
Só que verificar dá trabalho.
Exige ir além da manchete, identificar as versões afetadas, entender o caminho percorrido pela aleatoriedade e separar uma estimativa preliminar de um fato confirmado.
Também exige resistir a duas tentações.
A primeira é minimizar uma falha séria porque gostamos do produto ou confiamos na empresa.
A segunda é usar a mesma falha para condenar toda uma categoria de carteiras — ou insinuar que qualquer sistema com 24 palavras sofre do mesmo problema.
Nenhuma das duas posturas ajuda.
O que esse incidente ensina é mais específico e, justamente por isso, mais útil: bons algoritmos não compensam uma origem previsível.
Não basta o dispositivo possuir um gerador de hardware. É preciso verificar se o caminho que cria a seed realmente chega até ele.
Ao fazer a mesma pergunta sobre o LND, encontramos um caminho diferente: 128 bits vindos diretamente do gerador criptográfico do sistema operacional e usados na raiz da carteira.
Segurança no Bitcoin não precisa nascer do medo.
Pode nascer da curiosidade, da leitura do código, da comparação entre fontes e da disposição para revisar até aquilo que já parece bem estabelecido.
Don’t trust. Verify. Mas, antes de espalhar, compreenda.
Fontes consultadas
Análise técnica da Coinkite:
https://blog.coinkite.com/entropy-technical-backgrounder/
Análise da equipe de segurança da Block:
https://engineering.block.xyz/blog/predictable-rng-fallback-and-32-bit-reseed-in-coldcard-firmware
Documentação do aezeed:
https://github.com/lightningnetwork/lnd/blob/master/aezeed/README.md
Documentação do crypto/rand:
https://pkg.go.dev/crypto/rand