Entropia e Aleatoriedade em Criptomoedas: Por Que Isso Importa

Toda chave privada de criptomoeda, toda seed phrase e todo endereço que você usa começa com um número aleatório. A segurança de todo o seu portfólio cripto depende de uma suposição: esse número era realmente imprevisível. Se o gerador de números aleatórios que produziu sua chave for fraco, tendencioso ou previsível, seus fundos podem ser roubados, não por quebrar a criptografia, mas por adivinhar a chave.

Este guia explica o que entropia significa em um contexto criptográfico, como os geradores de números aleatórios funcionam, o que historicamente deu errado quando a aleatoriedade falhou e como garantir que sua geração de chaves seja confiável.

O Que É Entropia?

Na teoria da informação, entropia mede a quantidade de incerteza ou imprevisibilidade em um dado. Na criptografia, a entropia quantifica quantos bits de aleatoriedade genuína um valor contém.

Uma chave privada de 256 bits deve ter 256 bits de entropia, o que significa que um atacante precisa tentar, em média, 2^255 palpites para encontrá-la (metade do espaço de busca, em média). Se a chave foi gerada com apenas 32 bits de entropia real (porque o RNG tinha falhas), o atacante precisa de apenas cerca de 2^31 palpites, aproximadamente 2 bilhões, algo que um computador moderno consegue esgotar em minutos.

Medindo Entropia

A entropia é medida em bits. A entropia de uma variável aleatória X é:

H(X) = -sum(p(x) * log2(p(x))) for all possible values x

Para um número de 256 bits uniformemente aleatório:

• Cada bit tem probabilidade 0.5 de ser 0 ou 1.
• Entropia = 256 bits (máximo para esse tamanho).

Para um gerador tendencioso em que cada bit tem probabilidade 0.7 de ser 1:

• Entropia por bit = -(0.7 * log2(0.7) + 0.3 * log2(0.3)) = 0.881 bits.
• Entropia total para 256 bits = 225.5 bits (11.9% menor que o ideal).

Mesmo pequenos vieses se acumulam ao longo de muitos bits e podem reduzir significativamente o nível de segurança efetivo.

Entropia no Contexto do BIP-39

Tamanho do Mnemônico	Entropia	Nível de Segurança	Brute-Force a 10^12/seg
12 palavras	128 bits	128-bit	~10^19 anos
15 palavras	160 bits	160-bit	~10^28 anos
18 palavras	192 bits	192-bit	~10^38 anos
24 palavras	256 bits	256-bit	~10^57 anos

Esses números assumem que a entropia é realmente uniforme. Se o RNG tiver falhas, o nível de segurança real pode ser drasticamente menor.

Tipos de Geradores de Números Aleatórios

True Random Number Generators (TRNG)

TRNGs amostram fenômenos físicos inerentemente imprevisíveis no nível quântico:

• Ruído térmico — Flutuações aleatórias de tensão em resistores causadas pela agitação térmica dos elétrons.
• Shot noise — Flutuações aleatórias na corrente devido à natureza discreta do fluxo de elétrons.
• Decaimento radioativo — O tempo de eventos individuais de decaimento é fundamentalmente imprevisível.
• Ruído atmosférico — Ruído de radiofrequência de raios e outros processos atmosféricos.

Hardware wallets como Ledger e Trezor usam TRNGs no chip. Eles amostram fontes de ruído físico e condicionam a saída por meio de whitening e testes de integridade.

Vantagens: Aleatoriedade real da física; nenhum estado determinístico para prever.
Desvantagens: Dependente de hardware; pode falhar silenciosamente se a fonte de ruído degradar; a taxa pode ser limitada.

Cryptographically Secure Pseudo-Random Number Generators (CSPRNG)

Um CSPRNG é um algoritmo determinístico que produz saída indistinguível de aleatoriedade real, dado um seed suficientemente aleatório:

• Linux: /dev/urandom (usa ChaCha20 ou cifra semelhante, seed a partir de entropia de hardware).
• macOS: /dev/urandom (arc4random, seed a partir de entropia de hardware).
• Windows: BCryptGenRandom (provedor CNG).
• Navegadores web: crypto.getRandomValues() (delegado ao CSPRNG do SO).
• Python: os.urandom() ou módulo secrets.
• Node.js: crypto.randomBytes().

Vantagens: Rápido; algoritmos bem estudados; disponível em todas as plataformas.
Desvantagens: Tão forte quanto a entropia inicial do seed; determinístico, se o estado interno for conhecido, toda saída futura é previsível.

PRNGs Não Criptográficos (NUNCA Use para Chaves)

As funções aleatórias padrão da biblioteca na maioria das linguagens de programação são projetadas para simulação estatística, não para criptografia:

• Python: random.random() (Mersenne Twister — determinístico, estado recuperável a partir de 624 saídas).
• JavaScript: Math.random() (xorshift128+ no V8 — previsível).
• C: rand() (gerador congruencial linear — trivialmente previsível).
• Java: java.util.Random (congruencial linear — previsível).

Esses geradores têm baixa entropia, períodos curtos e estado previsível. Usá-los para geração de chaves equivale a não usar aleatoriedade nenhuma. Nunca gere chaves privadas ou seed phrases com essas funções.

Falhas Históricas de Aleatoriedade

O Bug do Android SecureRandom (2013)

Em agosto de 2013, foi descoberta uma falha crítica na implementação do SecureRandom do Android. O PRNG em Java não era semeado corretamente em certos dispositivos Android, fazendo com que vários apps de carteira Bitcoin gerassem chaves privadas a partir de um estado previsível. Um atacante explorou isso para roubar aproximadamente 55 BTC. O bug afetava a geração do nonce de assinatura ECDSA: usar o mesmo nonce duas vezes permite calcular a chave privada a partir de duas assinaturas.

O "Blockchain Bandit" (2019)

O pesquisador de segurança Adrian Bednarek descobriu que carteiras haviam sido geradas com chaves privadas trivialmente fracas, chaves como 1, 2, 3 ou palavras simples de dicionário aplicadas uma vez em hash. Um atacante vinha varrendo sistematicamente fundos desses endereços por anos, acumulando mais de 45.000 ETH. O bandido simplesmente enumerava chaves de baixa entropia e verificava se tinham fundos.

Exemplos de chaves drenadas:

• Chave privada 0x0000000000000000000000000000000000000000000000000000000000000001 (o número 1)
• Chaves privadas derivadas de senhas e frases comuns

A Vulnerabilidade Milk Sad (2023)

O comando seed da ferramenta libbitcoin-explorer (bx) usava Mersenne Twister semeado com apenas 32 bits de tempo do sistema. Isso significava que todas as chaves geradas com essa ferramenta tinham no máximo 32 bits de entropia, aproximadamente 4,3 bilhões de possibilidades. Atacantes fizeram brute-force dessas chaves e roubaram fundos.

O Bug de Chave Fraca do Debian OpenSSL (2008)

Um mantenedor do Debian removeu acidentalmente uma linha de código que fornecia entropia ao gerador de números aleatórios do OpenSSL. Por dois anos (2006-2008), toda chave criptográfica gerada em sistemas Debian e Ubuntu tinha apenas 15 bits de entropia vindos do ID do processo, produzindo no máximo 32.767 chaves únicas. Todas as chaves SSH, certificados SSL e quaisquer chaves de criptomoeda geradas nesse período em sistemas afetados ficaram comprometidas.

Lições Aprendidas

1. Nunca confie em uma única fonte de entropia sem verificação.
2. Pequenos erros de implementação podem reduzir a entropia de forma catastrófica.
3. Atacantes exploram ativamente aleatoriedade fraca, isso não é teórico.
4. Código open-source e auditado é essencial para operações críticas de entropia.

Fontes de Entropia em Detalhe

Pool de Entropia do Sistema Operacional

Sistemas operacionais modernos mantêm um pool de entropia alimentado por múltiplas fontes:

• Tempo de interrupções — O tempo de interrupções de hardware (teclado, mouse, disco, rede) fornece entrada imprevisível.
• Tempo de I/O de disco — O tempo exato de operações de leitura/escrita em disco varia devido a fatores mecânicos e eletrônicos.
• RNG de hardware — CPUs modernas (Intel RDRAND, AMD) incluem geradores de números aleatórios no chip.
• Entropia no boot — Alguns sistemas salvam entropia entre reinicializações (/var/lib/systemd/random-seed no Linux).

O SO mistura essas fontes em um pool de entropia usando primitivas criptográficas e depois usa o pool para semear seu CSPRNG. Em kernels Linux modernos (5.18+), /dev/urandom bloqueia até coletar entropia suficiente no boot e depois não bloqueia novamente.

Entropia no Navegador (crypto.getRandomValues)

Quando você usa uma ferramenta web como o gerador da SafeSeed, a API crypto.getRandomValues() do navegador é usada. Ela delega ao CSPRNG do sistema operacional:

• Chrome: Delega ao CSPRNG do SO (BoringSSL).
• Firefox: Delega ao CSPRNG do SO (NSS).
• Safari: Delega ao CSPRNG do SO (CommonCrypto).

Isso é considerado seguro para geração de chaves, desde que o SO subjacente seja seguro. A principal preocupação é executar em um ambiente onde o CSPRNG do SO possa estar comprometido (por exemplo, uma máquina virtual com fontes de entropia insuficientes ou um sistema operacional comprometido).

Entropia de Hardware Wallet

Hardware wallets usam true random number generators no chip:

• Ledger (Secure Element ST33): Usa o TRNG do chip ST33, que amostra ruído analógico. A saída passa por testes de integridade NIST SP 800-90B antes do uso.
• Trezor: Usa o RNG de hardware do chip STM32. O Trezor também suporta mistura com entropia fornecida pelo usuário via rolagem de dados.
• Coldcard: Usa o TRNG do secure element ATECC608A mais o RNG de hardware do MCU, misturando as duas fontes.

Entropia por Rolagem de Dados

Rolar dados manualmente é o método mais transparente de geração de entropia:

• Um dado justo de seis faces produz log2(6) = 2.585 bits de entropia por rolagem.
• 100 rolagens produzem aproximadamente 258.5 bits de entropia, suficiente para uma seed phrase de 24 palavras.
• O usuário pode verificar fisicamente a aleatoriedade (dados justos, rolagens justas, sem manipulação).

Verificando a justiça dos dados:

• Use dados de precisão de cassino (arestas vivas, não arredondadas).
• Role em uma superfície dura e plana com anteparo.
• Não "posicione" os dados, deixe-os rolar livremente.
• Registre cada resultado imediatamente e em sequência.

Ferramenta SafeSeed

O SafeSeed Seed Phrase Generator permite inserir sua própria entropia (como resultados de rolagem de dados) para gerar uma seed phrase BIP-39. Isso permite verificar a fonte de aleatoriedade enquanto você ainda se beneficia da implementação correta de BIP-39 da ferramenta. Use a ferramenta offline para máxima segurança, veja nosso guia de geração de chaves offline.

Testando e Verificando Aleatoriedade

NIST Statistical Test Suite

A NIST SP 800-22 define uma bateria de testes estatísticos para avaliar geradores de números aleatórios:

• Teste de frequência — Há aproximadamente a mesma quantidade de 0s e 1s?
• Teste de frequência em blocos — Sub-blocos de bits estão aproximadamente distribuídos de forma igual?
• Teste de runs — Sequências de bits idênticos consecutivos (runs) têm comprimento esperado?
• Teste de run mais longo — O run mais longo está dentro dos limites esperados?
• Teste de posto de matriz — Postos de matrizes binárias seguem distribuições esperadas?
• Teste espectral — A DFT da sequência de bits mostra propriedades esperadas?

Esses testes podem detectar vieses e padrões, mas não podem provar que um gerador é seguro. Eles só podem detectar falhas.

Dieharder Test Suite

Uma bateria estatística mais abrangente que inclui os testes originais Diehard mais testes adicionais. Disponível como software open-source no Linux.

Verificação Prática para Usuários

A maioria dos usuários não consegue executar as suítes de teste NIST. Passos práticos de verificação:

1. Verificação da fonte — A ferramenta usa crypto.getRandomValues(), os.urandom() ou RNG de hardware? Verifique o código-fonte.
2. Teste de gerações cruzadas — Gere múltiplas seed phrases e verifique se são diferentes a cada vez.
3. Exibição de entropia — Algumas ferramentas mostram a entropia bruta, verifique se parece aleatória (sem padrões óbvios).
4. Auditoria open-source — A ferramenta é open-source e foi auditada?

Misturando Fontes de Entropia

A melhor prática para geração de chaves de alta segurança é misturar múltiplas fontes de entropia:

Final Entropy = Hash(Hardware RNG output || OS CSPRNG output || User dice rolls || Timing data)

Misturar fontes garante que, mesmo se uma fonte estiver comprometida ou com viés, a saída final permaneça segura desde que pelo menos uma fonte forneça entropia suficiente. Essa é a abordagem usada por hardware wallets e ferramentas de geração de chaves bem projetadas.

Mistura com XOR

Um método simples de mistura é XOR: se você tem 256 bits da fonte A e 256 bits da fonte B:

Mixed = A XOR B

Se A ou B for realmente aleatória, o resultado é realmente aleatório. Se ambas forem tendenciosas, mas independentes, o resultado é menos tendencioso que cada uma individualmente.

Mistura com Hash

Para misturar fontes de diferentes comprimentos ou qualidades, aplique hash nelas juntas:

Mixed = SHA-256(Source_A || Source_B || Source_C)

A função hash atua como extrator de entropia, produzindo uma saída uniforme independentemente do formato da entrada.

Entropia em Configurações Multi-Signature

Carteiras multi-signature fornecem uma forma de redundância de entropia: mesmo que uma chave tenha sido gerada com entropia fraca, o atacante ainda precisa comprometer as outras chaves. Uma multisig 2-de-3 em que cada chave é gerada de forma independente oferece segurança igual à chave mais forte, não à mais fraca.

Esse é um argumento poderoso para configurações multi-signature em armazenamento de alto valor.

FAQ

O que é entropia em criptomoedas?

Entropia é a medida de aleatoriedade ou imprevisibilidade nos dados usados para gerar chaves criptográficas. Em criptomoedas, a segurança das suas chaves privadas e seed phrases depende totalmente de ter entropia suficiente. Uma chave de 256 bits deve conter 256 bits de aleatoriedade real, se a entropia for menor, a chave se torna adivinhável.

Quanta entropia eu preciso para uma carteira segura?

Uma seed phrase BIP-39 de 12 palavras fornece 128 bits de entropia, e uma frase de 24 palavras fornece 256 bits. Ambas são consideradas seguras contra ataques de brute-force com a tecnologia atual. Para armazenamento de longo prazo com alto valor, 256 bits (24 palavras) é recomendado para fornecer margem máxima de segurança.

Math.random() é seguro para gerar chaves cripto?

Absolutamente não. Math.random() e PRNGs não criptográficos semelhantes (o random do Python, o rand() do C) são determinísticos, previsíveis e têm baixa entropia. Eles nunca devem ser usados para geração de chaves criptográficas. Sempre use crypto.getRandomValues() em navegadores, os.urandom() em Python ou um gerador de números aleatórios de hardware.

Posso gerar minha própria entropia pensando em números aleatórios?

Não. Humanos são notoriamente ruins em gerar números aleatórios. Estudos mostram consistentemente que sequências "aleatórias" escolhidas por humanos têm muito menos entropia do que parecem. Em vez disso, use um processo físico (dados, RNG de hardware) ou um RNG de software criptograficamente seguro.

Como verifico se o gerador de números aleatórios da minha carteira é seguro?

Verifique o código-fonte da carteira (se for open-source) para confirmar que usa um CSPRNG ou TRNG de hardware. Procure chamadas para crypto.getRandomValues(), os.urandom() ou APIs de RNG de hardware. Para hardware wallets, verifique a documentação de segurança do fabricante e relatórios de auditoria de terceiros.

O que é o "blockchain bandit" e o que ele ensina sobre entropia?

O "blockchain bandit" é um atacante que roubou sistematicamente criptomoedas de carteiras geradas com chaves privadas fracas (como os números 1, 2, 3 ou chaves derivadas de senhas simples). Isso mostrou que atacantes enumeram ativamente chaves de baixa entropia e varrem quaisquer fundos que encontram. Isso reforça a importância crítica de usar geração de números aleatórios com alta entropia.

Os geradores de números aleatórios de hardware wallets são confiáveis?

TRNGs de hardware wallet geralmente são confiáveis, mas representam um único ponto de confiança. Para segurança máxima, você pode misturar a saída do RNG de hardware com entropia fornecida pelo usuário (rolagens de dados). Algumas hardware wallets (como Trezor e Coldcard) suportam essa mistura nativamente. Isso garante que, mesmo se o RNG de hardware estiver comprometido, a chave resultante permaneça segura.

O sistema operacional (Linux, macOS, Windows) afeta a segurança da chave?

Sim. A qualidade e a implementação do CSPRNG do SO afetam a segurança da chave. Versões modernas de Linux, macOS e Windows fornecem geradores de números aleatórios criptograficamente seguros (/dev/urandom, arc4random, BCryptGenRandom). No entanto, o bug Debian OpenSSL de 2006-2008 mostrou que vulnerabilidades no nível do SO podem reduzir a entropia de forma catastrófica. Mantenha seu SO atualizado e use software bem auditado.

Guias Relacionados

• Seed Phrase: O Guia Completo
• Guia de Geração de Chaves Offline
• Guia de Segurança de Chave Privada
• Padrão BIP-39 Explicado
• Computação Quântica e Criptomoeda