Entropia (Shannon)

Entropia na teoria da informação (entropia de Shannon) mede o quão imprevisível é uma variável aleatória, em bits. Uma fonte de entropia de 1 bit pode produzir 2 resultados igualmente prováveis; n bits de entropia podem produzir 2ⁿ. Matematicamente: H = log₂(N) para N resultados igualmente prováveis.

Exemplos:

• Lançamento de uma moeda justa: 1 bit.
• Lançamento de um dado justo: log₂(6) ≈ 2,58 bits.
• Senha aleatória de 8 caracteres minúsculos: 8 × log₂(26) ≈ 37,6 bits.
• Senha aleatória de 16 caracteres de [a-z A-Z 0-9 símbolos]: 16 × log₂(94) ≈ 104,9 bits.
• UUID v4: 122 bits (6 bits são constantes de versão/variante).

Por que a entropia importa para segredos: um atacante que força sua senha tenta combinações uma a uma. O trabalho esperado é 2ⁿ⁻¹ tentativas onde n é a entropia da sua senha. A um bilhão de tentativas por segundo:

• 40 bits: ~9 minutos para forçar. Inadequado.
• 60 bits: ~17 anos. Marginal.
• 80 bits: ~38 milhões de anos. Adequado.
• 128 bits: morte térmica do universo antes do esgotamento. Nível criptográfico.

Pegadinha comum: a entropia depende da distribuição, não apenas do valor. Uma senha “aleatória” escolhida por um humano (“Password123!”) tem muito menos entropia do que seu comprimento sugere, porque o processo de seleção humana não é uniforme. Senhas aleatórias geradas por computador (via crypto.getRandomValues ou /dev/urandom) atingem a entropia teórica completa do seu conjunto de caracteres.

Use nosso gerador de senhas para ver o medidor de entropia ao vivo enquanto você ajusta o comprimento e as classes de caracteres.

Exemplo prático

Três senhas para a mesma conta imaginária, classificadas por entropia de Shannon. Primeira: Password123! — 12 caracteres, parece “forte” em comprimento, mas a estrutura (palavra do dicionário + dígitos sequenciais + pontuação óbvia) reduz a entropia efetiva para cerca de 20-25 bits porque os atacantes usam dicionários baseados em regras (o best64 do hashcat, OneRuleToRuleThemAll) que tentam exatamente esse padrão. Quebrável em menos de um minuto. Segunda: uma frase Diceware como correct horse battery staple — quatro palavras da lista Diceware de 7.776 palavras, entropia = 4 × log₂(7776) ≈ 51,7 bits. Resistente a ataques de dicionário por anos em uma única GPU. Terceira: 16 caracteres aleatórios de um alfabeto de 94 caracteres via crypto.getRandomValues: 16 × log₂(94) ≈ 104,8 bits. Computacionalmente inviável de forçar com qualquer tecnologia atual ou previsível. A lição: a entropia vem do processo de geração, não de parecer complicado.

Uma sutileza importante: entropia não é o mesmo que comprimento. Uma senha de 30 caracteres retirada apenas de letras minúsculas tem 30 × log₂(26) ≈ 141 bits — forte. Mas uma “senha” de 30 caracteres que é na verdade uma citação de um livro famoso tem talvez 20-30 bits porque o espaço de busca é o catálogo de citações famosas, não todas as strings possíveis de 30 caracteres. Os atacantes miram na distribuição real, não na nominal.

Quando e por que isso importa

Entropia importa sempre que um segredo precisa resistir a adivinhações: senhas, chaves de API, tokens de sessão, chaves de criptografia e as sementes para qualquer operação criptográfica. O NIST SP 800-63B (a orientação moderna sobre senhas) recomenda explicitamente um mínimo de 80 bits para segredos de longo prazo e 128 bits para chaves criptográficas. O erro mais comum é gerar valores “aleatórios” usando Math.random() — que é um PRNG não criptográfico com no máximo 52 bits de estado efetivo e é trivialmente previsível a partir de algumas saídas. Para qualquer aleatoriedade relevante para segurança, use crypto.getRandomValues() em navegadores, crypto.randomBytes() no Node, secrets.token_*() em Python ou SecureRandom em Java/JVM. O segundo erro é reutilizar um token de sessão ou nonce em várias sessões; mesmo um valor de 128 bits reutilizado enfraquece o sistema para qualquer canal que vazou o original. Referência: NIST SP 800-63B — Diretrizes de Identidade Digital.

Fontes de entropia por hardware vs software: os sistemas operacionais modernos coletam entropia de ruído físico — jitter de tempo de teclado, movimento do mouse, tempos de chegada de pacotes de rede e, em CPUs recentes, instruções de ruído térmico dedicadas (RDRAND na Intel, RDSEED na AMD). O /dev/random do Linux historicamente bloqueava quando o pool de entropia estava baixo; o /dev/urandom mistura o pool por meio de um CSPRNG e nunca bloqueia. A partir do Linux 5.18 (2022), os dois são essencialmente equivalentes — ambos seguros para uso criptográfico após a coleta de entropia no boot. VMs em nuvem e contêineres podem ter entropia fraca no boot; a geração de chaves criptográficas em uma VM recém-iniciada é um dos poucos casos restantes em que aguardar brevemente o acúmulo de entropia faz diferença mensurável. Referência: RFC 4086 — Requisitos de Aleatoriedade para Segurança.