Falhas de RNG: a história das seeds previsíveis

Por KriptoBR · Publicado em 02 de agosto de 2026 · Leitura de 14 minutos

O que é RNG e por que a sua seed depende dele

Quando uma carteira cria uma frase de recuperação de 12 ou 24 palavras (BIP-39), ela não está “inventando” palavras: está sorteando um número gigantesco — 128 ou 256 bits de entropia — e codificando esse número em palavras legíveis. A segurança de todo o sistema depende de uma única premissa: esse número precisa ser impossível de adivinhar.

Com 128 bits de entropia genuína, existem cerca de 340 undecilhões de combinações possíveis (um 3 seguido de 38 zeros). Nenhum computador do planeta consegue percorrer esse espaço. O responsável por produzir essa aleatoriedade é o gerador de números aleatórios — o RNG. E é aqui que mora o perigo, porque existem dois tipos muito diferentes de gerador:

• CSPRNG / TRNG — geradores criptograficamente seguros (por software, alimentados pelo sistema operacional) ou geradores verdadeiros por hardware (TRNG), que extraem imprevisibilidade de fenômenos físicos. São os únicos adequados para criar chaves.
• PRNG comum — geradores estatísticos como Mersenne Twister, Math.random(), rand() do PHP ou o Random() do Dart. Servem para simulações e jogos, mas são determinísticos: quem conhece (ou consegue chutar) a semente inicial reproduz toda a sequência.

O ataque clássico funciona assim: se um software semeia um PRNG comum com o relógio do sistema, o espaço de busca despenca de 2¹²⁸ para algo como 2³² — cerca de 4 bilhões de possibilidades. Um atacante gera todas as seeds candidatas, deriva os endereços de cada uma, cruza com os dados públicos da blockchain e descobre, sem nunca tocar no dispositivo da vítima, quais carteiras ele consegue esvaziar. É por isso que esse tipo de falha é tão devastador: o roubo acontece à distância, em massa e de uma vez só.

2026: o ano em que o problema bateu na porta

O caso COLDCARD

Na noite de 30 de julho de 2026, um atacante varreu 1.195 endereços Bitcoin em cerca de 41 minutos, levando 1.082,65 BTC. Nos dois dias seguintes vieram mais duas ondas. O balanço consolidado pela Galaxy Research: 1.367,05 BTC (~US$ 88,6 milhões) drenados de 4.585 endereços — quase todos carteiras single-sig criadas em dispositivos COLDCARD, da fabricante canadense Coinkite. A taxa fixa de 30 sat/vB usada em milhares de transações indicou uma ferramenta automatizada, e o primeiro saque ocorreu cerca de 30 horas antes de qualquer comunicado oficial.

A causa raiz, documentada pela equipe de engenharia Bitcoin da Block e confirmada pela própria Coinkite, foi um erro de integração de firmware introduzido em março de 2021: uma verificação de compilação mal construída (um #ifndef que testava se uma macro existia, e não o seu valor) fez o processo de geração de seed ignorar silenciosamente o gerador de hardware (TRNG) do chip e cair num PRNG de software chamado Yasmarang, semeado com valores previsíveis — o identificador do chip e contadores de tempo internos. Resultado: seeds com segurança efetiva estimada em ~40 bits nos modelos Mk2/Mk3 (firmware das séries 4.0–4.1; a v4.2.0 corrige) e ~72 bits nos Mk4, Mk5 e Q, afetados em menor grau graças a uma re-semeadura parcial adicionada em 2022. O CTO da empresa reconheceu publicamente, em primeira pessoa, que a maior parte da aleatoriedade vinha de um gerador que ele não sabia estar ativo no código, enquanto o TRNG que ele mesmo escreveu acabava usado apenas para funções menos críticas.

Dois detalhes tornam o caso didático. Primeiro: o código vulnerável era aberto e público havia cinco anos — análises independentes, como a do desenvolvedor brasileiro Fabio Akita, classificaram o episódio como um “cisne branco”: não um evento imprevisível, mas um erro visível que ninguém verificou na função mais crítica do produto. Segundo, como resumiu a cobertura do CoinDesk: a maioria dos roubos exige alcançar a chave da vítima; aqui, a chave foi reconstruída à distância, sem tocar no dispositivo — que podia estar desligado dentro de um cofre. “Cold storage” prometia uma chave impossível de adivinhar; muita gente leu como impossível de alcançar.

Um registro de transparência: a COLDCARD nunca fez parte do portfólio da KriptoBR. Por experiências próprias com a marca desde 2018, a empresa decidiu não comercializá-la nem recomendá-la — posição que mantivemos ao longo dos anos e que segue inalterada.

Ill Bloom: o aviso que veio três semanas antes

O caso COLDCARD nem foi o primeiro alarme de 2026. Em 10 de julho, a empresa de auditoria Coinspect divulgou a vulnerabilidade Ill Bloom: cinco implementações de carteira de software (nomes ainda não revelados, por divulgação em fases) geravam frases de recuperação com um PRNG inseguro. Carteiras criadas desde 2018 foram afetadas, em redes como Bitcoin, Ethereum, Polygon, Rootstock, Tron e Solana. Em 27 de maio, atacantes varreram 431 carteiras em poucas horas, e as perdas já superavam US$ 5,1 milhões na divulgação. A lição da Coinspect vale para todos os casos deste artigo: uma frase criada com entropia insuficiente carrega a fraqueza para sempre — atualizar o aplicativo depois não muda nada.

Foi nesse contexto que Jameson Lopp, um dos pesquisadores de segurança mais respeitados do ecossistema Bitcoin, publicou sua lista: geração fraca de números aleatórios “não é um problema novo”. A seguir, o histórico completo — organizado em três eras.

Primeira era (2011–2015): navegadores e Android sorteando mal

Randstorm: BitcoinJS, bitaddress.org, CoinPunk, QuickCoin e a Blockchain.info

Entre 2011 e 2015, a forma mais comum de criar uma carteira era o navegador. A biblioteca JavaScript BitcoinJS — e a função SecureRandom() herdada da biblioteca JSBN — sustentava geradores como bitaddress.org (versões antigas, pré-2013), brainwallet.org, CoinPunk, QuickCoin e a carteira web da Blockchain.info (hoje Blockchain.com), além de serviços como Dogechain, BitGo e Blocktrail. O problema, revelado só em novembro de 2023 pela pesquisa Randstorm, da Unciphered: por um erro de verificação, o código deixava de usar a API criptográfica do navegador (window.crypto) e caía no Math.random() — que nunca foi feito para criptografia e, nos navegadores da época, era ainda mais fraco. A estimativa da Unciphered: milhões de carteiras criadas nesse período, somando cerca de 1,4 milhão de BTC, potencialmente vulneráveis. Já em 2018 o pesquisador David Gerard havia soado esse alarme para carteiras antigas geradas em navegador.

O bug do SecureRandom no Android (2013)

Em agosto de 2013, o site oficial bitcoin.org publicou um alerta raro: um componente do Android responsável por gerar números aleatórios seguros tinha falhas críticas, deixando todas as carteiras geradas em apps Android vulneráveis. A lista incluía o Bitcoin Wallet de Andreas Schildbach, o BitcoinSpinner, a Mycelium Bitcoin Wallet e o app Android da Blockchain.info. A implementação do SecureRandom em Java no Android inicializava mal o gerador — uma análise acadêmica posterior mostrou que 12 dos 20 bytes de entropia pedidos ao sistema simplesmente se perdiam no caminho. O defeito produziu chaves fracas e, pior, repetição do valor “R” em assinaturas ECDSA — uma falha matemática que permite extrair a chave privada de duas assinaturas. Mais de 55 BTC foram roubados antes mesmo do anúncio. A correção exigiu ler entropia direto de /dev/urandom e rotacionar todas as chaves: cada usuário precisou enviar seus próprios fundos para endereços novos.

Blockchain.info: dois tropeços seguidos

A mesma Blockchain.info viveu dois episódios próprios. Ainda em agosto de 2013, a falha de valores “R” repetidos atingiu também seu cliente web, extensões de navegador e app para Mac — a empresa corrigiu em horas e reembolsou vítimas. Em dezembro de 2014, uma atualização malfeita fez o serviço gerar chaves privadas inseguras por algumas horas; cerca de 250 BTC ficaram expostos e foram varridos por um “white hat” conhecido como johoe, que dias depois devolveu 255 BTC aos donos legítimos. Foi um final feliz raro — e um lembrete de que quem varre a blockchain à procura de chaves fracas nem sempre devolve.

Brainwallets: quando o “gerador” é o cérebro humano

O brainwallet.org popularizou a pior ideia possível: derivar a chave privada do hash de uma frase escolhida pelo usuário. Humanos são geradores de entropia péssimos — escolhem letras de música, citações e senhas reaproveitadas. Em 2015, o pesquisador Ryan Castellucci apresentou o Brainflayer, capaz de testar bilhões de frases e varrer os fundos em segundos; milhares de brainwallets foram esvaziadas e o site saiu do ar no mesmo ano. A equipe Milk Sad revisitou o tema em janeiro de 2026 e publicou coleções inteiras de endereços fracos desse tipo — hoje, qualquer brainwallet é considerada dinheiro perdido por antecipação.

O gerador do presale do Ethereum (2014)

A lista de Lopp inclui também o gerador de carteiras do presale do Ethereum, usado entre julho e setembro de 2014 para criar os arquivos JSON dos primeiros compradores de ETH. A geração acontecia no navegador do participante — que “mexia o mouse” para alimentar a aleatoriedade —, exatamente a geração em browser cuja fragilidade a era Randstorm escancarou. Somando-se os bugs conhecidos de codificação de senha daquela ferramenta, os wallets do presale se tornaram um capítulo próprio na história das recuperações difíceis.

Segunda era (2018–2022): apps, bibliotecas e endereços personalizados

Trust Wallet para iOS (2018)

Em janeiro de 2024, o time da SECBIT Labs revelou que versões de 2018 do Trust Wallet para iOS criavam carteiras usando funções da biblioteca trezor-crypto que não foram feitas para produção — um gerador de teste com estado inicial de 31 bits, semeado com valores de tempo fáceis de estimar. Todas as carteiras geradas por essas versões podiam ser reconstruídas remotamente por força bruta. A descoberta explicou parte dos grandes roubos coordenados de 12 de julho de 2023, quando atacantes drenaram simultaneamente carteiras fracas de origens diferentes.

Cake Wallet (2020–2021)

Versões da Cake Wallet lançadas em 2020 e 2021 geravam as seeds de Bitcoin com o Random() comum da linguagem Dart — em vez do Random.secure(), a variante criptográfica. O resultado, quantificado depois pela equipe Milk Sad: cerca de 20 bits de entropia efetiva, um dos piores casos já medidos. O próprio fornecedor divulgou a falha publicamente em maio de 2021, corrigiu na versão 4.1.7 e pediu que todos os usuários migrassem os fundos com urgência. A maioria migrou — mas não todos: revisitando o caso no fim de 2023 e em 2024, a Milk Sad ainda encontrou fundos parados nessas carteiras, mais de dois anos e meio depois do alerta. Um detalhe importante: o bug afetou apenas as seeds de Bitcoin (mnemônicos de 12 palavras no formato Electrum, tipo Segwit); as carteiras Monero do app nunca foram afetadas.

bip3x (2021)

A bip3x, uma biblioteca BIP-39 de código aberto usada para gerar mnemônicos em múltiplas plataformas, acumulou uma sequência de decisões perigosas, documentadas pela Milk Sad em janeiro de 2024: nas compilações para Windows (MinGW), a partir da versão 2.1.1 de fevereiro de 2021, usava o Mersenne Twister semeado com a hora do sistema; antes disso, o std::random_device do C++ chegava a falhar de forma determinística nesse ambiente — entregando, na prática, zero bits de entropia. E o padrão nas demais plataformas era um PRNG da família PCG, que não é criptograficamente seguro; o gerador seguro do OpenSSL existia, mas só como opção manual de compilação. É o retrato de um problema comum: bibliotecas que deixam o caminho inseguro como padrão e escondem o seguro atrás de uma flag.

Profanity e o caso Wintermute (2022)

O Profanity, gerador de “vanity addresses” para Ethereum (endereços com prefixos personalizados), criava chaves a partir de uma semente de apenas 32 bits — cerca de 4 bilhões de possibilidades, um espaço que GPUs modernas percorrem em horas. Em setembro de 2022, um atacante explorou exatamente isso para drenar aproximadamente US$ 160 milhões da market maker Wintermute, cujo endereço operacional havia sido gerado com a ferramenta. Pesquisadores depois reproduziram o ataque em menos de 48 horas usando um laptop. Bônus da mesma família: desde 2019 se conhecia o “Blockchain Bandit”, um atacante que monitorava 732 chaves Ethereum fracas e recolheu cerca de 45.000 ETH ao longo dos anos, no segundo em que qualquer valor chegava a elas.

PHPCoinAddress

A PHPCoinAddress, biblioteca PHP para gerar endereços Bitcoin, foi objeto de dois estudos da equipe Milk Sad no início de 2026, cobrindo as diferentes gerações de funções de aleatoriedade do PHP usadas pelo código — funções clássicas da linguagem que nunca foram adequadas para material criptográfico. Mais um lembrete de que “gera um endereço válido” não significa “gera um endereço seguro”.

Terceira era (2023–2026): a colheita dos atacantes

Milk Sad: Libbitcoin Explorer, o “bx seed” (2023)

Em julho de 2023, centenas de vítimas em várias blockchains perderam fundos num roubo coordenado. A investigação levou ao comando bx seed do Libbitcoin Explorer (versões 3.0.0 a 3.6.0), que gerava entropia com o Mersenne Twister MT19937 semeado com 32 bits de tempo — na definição dos próprios pesquisadores, os usuários guardavam fortunas sobre “um número de 32 bits vestido de chave privada”. A falha, divulgada publicamente em agosto de 2023, recebeu o nome Milk Sad (CVE-2023-39910), a partir das duas primeiras palavras do mnemônico mais previsível do gerador. Foram confirmadas mais de 2.600 carteiras fracas só na mainnet do Bitcoin, com danos estimados em US$ 900 mil no roubo de 12 de julho de 2023 — o mesmo evento que atingiu as carteiras antigas do Trust Wallet iOS. O grupo Milk Sad segue ativo até hoje e se tornou a principal referência mundial em pesquisa de carteiras com entropia fraca.

Trust Wallet, agora na extensão de navegador (2022–2023)

Em abril de 2023, o time Donjon, da Ledger, divulgou a CVE-2023-31290: versões da extensão de navegador do Trust Wallet distribuídas no fim de 2022 geravam seeds com cerca de 32 bits de entropia efetiva — de novo o Mersenne Twister —, reduzindo o universo de mnemônicos a aproximadamente 4 bilhões de combinações. Com poucas GPUs, um atacante percorreria tudo em menos de um dia, calculando chaves privadas diretamente a partir de endereços públicos. A falha foi corrigida após a divulgação responsável.

O caso lubian.com: bilhões sobre entropia fraca

Talvez o exemplo mais impressionante da escala do problema: em 2024, a equipe Milk Sad identificou uma faixa gigantesca de carteiras fracas ligadas ao antigo pool de mineração lubian.com, esvaziadas de uma só vez em dezembro de 2020. Em novembro de 2025, o Departamento de Justiça dos EUA revelou o confisco de 127 mil BTC (mais de US$ 14 bilhões na época) originários dessas carteiras — o maior confisco da história do órgão. Chaves derivadas de sementes previsíveis sustentavam, sem que ninguém soubesse, uma das maiores fortunas em Bitcoin do mundo.

2026: Ill Bloom e COLDCARD

E chegamos ao presente, já detalhado no início: cinco carteiras de software (Ill Bloom) e um dos hardware wallets mais conhecidos do mercado (COLDCARD) provaram que a lição segue não aprendida — agora com atacantes mais rápidos, ferramentas automatizadas e, segundo várias análises, o auxílio de inteligência artificial para localizar esse tipo de bug em código aberto. O protocolo Bitcoin não foi quebrado em nenhum desses casos; o que quebrou, sempre, foi o sorteio inicial.

Tabela-resumo: todas as falhas em um só lugar

O padrão que se repete: 5 lições

• 1. PRNG comum nunca é aceitável para chaves. Mersenne Twister, Math.random, Random() do Dart, rand() do PHP, PCG, Yasmarang — todos apareceram nesta lista. Chave privada só nasce de CSPRNG do sistema operacional ou TRNG de hardware verificado.
• 2. O vilão recorrente é o fallback silencioso. No Android, a entropia se perdia na inicialização; no JSBN, o código caía no Math.random sem avisar; na bip3x, o random_device falhava calado; na COLDCARD, um #ifndef mal avaliado desligou o TRNG sem nenhum alerta. Como resume a Coinspect: falha de aleatoriedade tem que ser fatal — o software deve parar, nunca degradar em silêncio.
• 3. Relógio não é segredo. Semear um gerador com o horário do sistema reduz o universo de chaves a poucos bilhões de opções — algo que um laptop percorre em horas e uma GPU em minutos.
• 4. Patch não conserta seed. A fraqueza fica gravada para sempre na frase de recuperação. A única correção real é gerar uma seed nova em ambiente confiável e migrar os fundos.
• 5. Código aberto ajuda, mas não se audita sozinho. O bug da COLDCARD ficou cinco anos exposto publicamente; o do JSBN, mais de uma década. Transparência só vira segurança quando alguém de fato verifica — e quando o fabricante trata a fonte de entropia como a função mais crítica do produto, com testes e revisão contínua.

Como proteger as suas chaves na prática

1. Nunca gere seed em navegador, site ou “gerador de paper wallet”. Toda a primeira era desta história aconteceu em páginas web. Se a geração roda num browser, trate a carteira como comprometida por padrão.
2. Gere as chaves em uma hardware wallet de fabricante idôneo, comprada de revendedor oficial. Dê preferência a dispositivos com TRNG dedicado e Secure Element certificado — os modelos atuais de Trezor, Ledger e SecuX seguem esse desenho (a linha Trezor Safe, por exemplo, usa Secure Element com certificação EAL6+). Comprar de canal oficial elimina o risco de adulteração na cadeia de suprimentos.
3. Adicione uma passphrase BIP-39. No caso COLDCARD, quem usava passphrase não foi drenado: mesmo reconstruindo a seed, o atacante não tinha a “25ª palavra”, que nunca é gerada nem armazenada pelo RNG do dispositivo. É a camada extra que separa um susto de um prejuízo.
4. Aposente seeds antigas de origem duvidosa. Se a sua frase nasceu em algum software da tabela acima — ou em qualquer app/site que você não consiga mais verificar —, crie uma seed nova em dispositivo confiável e transfira os fundos. Não espere o “seu” evento de varredura.
5. Mantenha o firmware atualizado — sabendo o que ele corrige. Atualização protege a geração de novas seeds e fecha outras brechas, mas jamais regenera a seed existente.
6. Proteja o backup fisicamente. Anote a frase offline e considere um backup em aço (como o KriptoSteel) contra fogo, água e tempo. E jamais digite a sua seed em site, formulário ou “verificador” online — inclusive os que prometem checar se ela é vulnerável. Os serviços sérios de consulta trabalham apenas com endereços públicos.

Perguntas frequentes

Fontes e leituras recomendadas: Block Engineering — análise técnica do RNG da COLDCARD · Coinkite — comunicado técnico · Galaxy Research (dados on-chain do ataque de 30/07–01/08/2026) · CoinDesk · Milk Sad — pesquisa de carteiras com entropia fraca (atualizações #4 bip3x, #5 Trust Wallet iOS, #6 Cake Wallet, #9 Cake Wallet técnico, #16 brainwallets, #20 Ill Bloom) · CVE-2023-39910 — write-up completo · SECBIT Labs — Trust Wallet iOS (2018) · bitcoin.org — alerta oficial do bug do Android (2013) · Randstorm (Unciphered) · The Register — SecureRandom() em JavaScript · Cointelegraph — caso johoe/Blockchain.info (2014) · Cointelegraph — Ill Bloom (Coinspect) · Coinspect — por que seeds fracas ficam em risco por anos · The Hacker News — COLDCARD (2026). Este conteúdo tem caráter informativo e educacional e não constitui recomendação de investimento.