Entropy Mixing

Imagine dois registros do mesmo acontecimento. Os nomes dos arquivos diferem, mas o segundo não acrescenta uma incógnita independente. Da mesma forma, os horários de chegada de pacotes e de acesso ao disco podem estar relacionados. A NIST SP 800-90B alerta que estimativas de entropia de fontes dependentes não podem ser simplesmente somadas. Primeiro é preciso determinar o que continua incerto se o atacante também conhece as outras entradas. [1]

Um hash é uma impressão digital calculada a partir dos dados. Mas, se o atacante conhece todas as entradas, pode calcular o mesmo resultado. Nem um hash longo nem uma constante pública acrescentada tornam essas entradas secretas. A RFC 4086 distingue misturar a incerteza disponível de produzir mais valores de forma determinística. Uma mistura bem projetada aproveita o que as fontes realmente oferecem; não substitui a entropia ausente. [2]

XOR compara bits: iguais resultam em zero, diferentes em um. Portanto, X XOR X = 0: combinar um valor com sua cópia elimina aqui toda a incerteza. Se, por outro lado, uma entrada for aleatória uniforme e independente da outra, o resultado permanece uniforme. A RFC 4086 mostra assim por que os pressupostos importam. Isso não é uma receita para construir um gerador caseiro de carteiras. [2]

Ao avaliar um projeto, pergunte de onde vêm as entradas e o que um atacante pode fazer com elas. HKDF, um método para derivar chaves criptográficas, usa uma entrada auxiliar chamada salt. Ela não precisa ser secreta, mas a RFC 5869 pressupõe independência em relação aos dados iniciais da chave e exige que a aplicação impeça sua escolha ou alteração por um atacante. Salt é um nome de parâmetro aqui. A lista de fontes ou uma saída aparentemente aleatória não garantem segurança quando uma fonte falha. [4]

A NIST SP 800-90B considera uma fonte principal de ruído. Permite acrescentar as saídas de outras fontes aos seus dados, desde que passem juntos por um método de processamento aprovado, chamado conditioning. Nesse regime, porém, não lhes atribui entropia adicional. Mais entradas não aumentam automaticamente a quantidade reconhecida. É uma regra dessa avaliação, não uma afirmação de que outras fontes nunca podem ajudar. [1]

A diferença aparece no OpenSSL 3.5, uma biblioteca criptográfica que programas podem usar para criptografia e números aleatórios. A função RAND_add() mistura dados de um buffer, uma área da memória destinada a armazená-los. num informa quantos bytes serão lidos; randomness estima sua entropia em bytes, de zero a num. O tamanho da área de memória não comprova essa estimativa. O gerador padrão normalmente se inicializa e repõe entropia automaticamente a partir de fontes do sistema. [3]

Fornecer entropia nova a um gerador é chamado de reseeding. Isso difere de acrescentar dados quaisquer. A documentação OpenSSL 3.5 explica que, no modo FIPS, sujeito a regras para módulos criptográficos, dados fornecidos pela aplicação não são aceitos como fonte confiável de entropia. São misturados apenas como entrada adicional e não contam como reseed completo. Chamar RAND_add() por si só não comprova essa renovação. [3]

O HKDF da RFC 5869 divide o trabalho em HKDF-Extract e HKDF-Expand. A primeira etapa concentra a entropia disponível em uma chave intermediária; a segunda deriva dela dados com o comprimento necessário. Isso não obtém outro segredo independente. O parâmetro info pode vincular o resultado ao uso pretendido, como indicar para que serve uma chave derivada. Esse contexto não substitui dados iniciais de qualidade nem comprova a criação de entropia. [4]