485 / 691MIX-H

Entropy Mixing

Mistura de entropia

Entropy Mixing combina entradas para gerar valores secretos. O benefício depende da imprevisibilidade, das dependências e do mecanismo concreto; a quantidade de fontes e o comprimento do hash, por si só, não determinam a segurança.

A mistura de entropia processa várias entradas num estado ou resultado comum. É preciso distinguir dados fornecidos, entropia comprovada e expansão determinística posterior. Dois nomes de interfaces não representam necessariamente duas fontes independentes.

NIST SP 800-90B observa que a entropia conjunta de fontes dependentes pode ser difícil de estimar. Tempos de chegada de pacotes e de acesso ao disco podem estar relacionados. As estimativas separadas não podem ser simplesmente somadas sem um modelo documentado. [NIST SP 800-90B — Additional noise sources]

RFC 4086 usa XOR como exemplo simples de mistura. Uma entrada uniforme independente preserva a uniformidade do resultado, mas uma cópia da mesma entrada produz X XOR X = 0. Isto ilustra a dependência, não uma receita de construção de carteira. [RFC 4086 — Mixing and randomness requirements]

Uma mistura robusta pode concentrar a incerteza disponível; um hash determinístico de entradas conhecidas continua previsível. RFC 4086 distingue mistura e expansão. O comprimento do resultado e adicionar uma constante conhecida não comprovam uma quantidade equivalente de entropia nova. [RFC 4086 — Mixing and randomness requirements]

NIST SP 800-90B permite concatenar ruídos adicionais com a fonte principal por condicionamento aprovado, mas não lhes atribui entropia adicional nesse regime. É uma regra de avaliação, não a afirmação de que outras fontes nunca podem ajudar. [NIST SP 800-90B — Additional noise sources]

Em OpenSSL 3.5, RAND_add() mistura num bytes; randomness estima a entropia em bytes entre zero e num. O tamanho do buffer não justifica essa estimativa. O gerador padrão normalmente inicializa e renova a semente automaticamente com fontes do sistema. [OpenSSL 3.5 — RAND_add and FIPS reseeding]

A documentação OpenSSL 3.5 diz que, em modo FIPS, dados da aplicação são apenas entrada adicional, não uma fonte de entropia confiável. Misturá-los não conta como reseed completo. Chamar RAND_add() por si só não comprova essa renovação. [OpenSSL 3.5 — RAND_add and FIPS reseeding]

RFC 5869 distingue HKDF-Extract e HKDF-Expand. O primeiro concentra a entropia de entrada; o segundo deriva o comprimento necessário. O parâmetro info associa o resultado ao contexto da aplicação; não substitui material inicial de qualidade nem comprova entropia nova. [RFC 5869 — HKDF extraction, expansion and independence]

A revisão deve identificar origem das entradas, dependências, capacidades do atacante e mecanismo concreto. RFC 5869 trata explicitamente da independência e da manipulação do salt. Uma lista de fontes ou um teste de aparência aleatória não comprovam segurança após a falha de uma fonte. [RFC 5869 — HKDF extraction, expansion and independence]

Para ter uma visão mais completa, leia este verbete junto com Cryptographic Entropy, CSPRNG, True Random Number Generator, Seed Generation. Também há referências a este verbete em Dice Roll Entropy, True Random Number Generator.

DOC · 001NIST SP 800-90B — Additional noise sourcesEspecificação ↗DOC · 002RFC 4086 — Mixing and randomness requirementsEspecificação ↗DOC · 003OpenSSL 3.5 — RAND_add and FIPS reseedingDocumentação ↗DOC · 004RFC 5869 — HKDF extraction, expansion and independenceEspecificação ↗
Fontes em primeiro lugar · Não é recomendação de investimento