Aspectos Internos de Hash-DRBG, HMAC-DRBG e CTR-DRBG

Cada um dos três mecanismos DRBG mantém componentes de estado interno diferentes, refletindo sua abordagem algorítmica subjacente. Hash_DRBG armazena V (uma semente do tamanho do hash) e C (uma constante derivada de V, usada durante a geração da saída). HMAC_DRBG armazena a chave secreta K (uma chave do tamanho do hash) e o valor V (um valor de encadeamento do tamanho do hash). CTR_DRBG armazena a chave K (uma chave do AES) e V (um contador do tamanho do bloco). Os três mantêm reseed_counter, que registra as chamadas a Generate desde a última semeadura. O tamanho do estado determina o uso de memória: Hash/HMAC_DRBG com SHA-256 usam 64 bytes de estado; CTR_DRBG com AES-256 usa 48 bytes (chave de 32 bytes + contador de 16 bytes).

Hash_DRBG usa Hash_df (função de derivação de hash) para derivar o estado a partir do material de entropia. Hash_df(input_string, no_of_bits_to_return) itera da seguinte forma: para counter = 1, 2, ..., calcule H(counter || no_of_bits || input_string) e concatene as saídas até que sejam produzidos bits suficientes. Isso expande entradas curtas de entropia em sementes do tamanho do estado. Durante Generate, a função de saída calcula W = H(0x03 || V), em que o prefixo 0x03 distingue esse uso de outros usos do hash. O laço de saída é: data = H(0x01 || V); V = V + 1; repita para gerar mais saída. Depois da geração, V é atualizado: V = V + H(0x03 || V) + C + reseed_counter. A separação de domínios por meio dos bytes de prefixo (0x01, 0x03) impede que a saída da fase de geração seja confundida com a fase de atualização do estado.

A função Update do HMAC_DRBG é o núcleo de todas as transições de estado. Update(provided_data, K, V): K = HMAC(K, V || 0x00 || provided_data); V = HMAC(K, V). Se provided_data não estiver vazio: K = HMAC(K, V || 0x01 || provided_data); V = HMAC(K, V). Essa atualização em duas etapas garante que tanto a nova chave quanto o novo valor dependam do estado anterior e de qualquer entropia nova. Generate: execute o laço V = HMAC(K, V) e anexe os resultados à saída até que sejam produzidos bits suficientes; depois chame Update com additional_input para avançar o estado. A segurança do HMAC_DRBG se reduz à suposição de que HMAC é uma PRF segura: um adversário que não consiga distinguir a saída do HMAC de uma saída aleatória também não conseguirá distinguir a saída do DRBG de uma saída aleatória.

CTR_DRBG usa Block_Cipher_df (função de derivação) para processar o material da semente no formato de chave/contador. Block_Cipher_df(input_string, no_of_bits) usa uma construção BCC (encadeamento de cifras de bloco): itera o AES-CBC sobre blocos de entrada para produzir uma saída do tamanho necessário. A função de derivação é necessária para lidar com entradas de entropia de comprimento variável e fornecer separação de domínios. CTR_DRBG sem uma função de derivação (permitido em testes FIPS com entradas formatadas com precisão) é mais rápido, mas mais sensível aos requisitos de formatação da entrada. O laço de Generate é: temp = E(K, V); V = V + 1; anexe temp à saída. Update: K || V = Block_Cipher_df(V || additional_input, seedlen); aplique XOR com a chave atual.

O desempenho varia significativamente entre os tipos de DRBG. Em uma CPU x86_64 moderna com AES-NI: CTR_DRBG (AES-256) atinge aproximadamente 5–10 GB/s de saída pseudoaleatória — a instrução AES-NI torna o cálculo do AES praticamente gratuito. HMAC_DRBG (SHA-256) atinge aproximadamente 200–400 MB/s — o SHA-256 é rápido, mas não é acelerado por hardware no mesmo grau. Hash_DRBG (SHA-256) atinge aproximadamente 100–300 MB/s. Para geração em massa de chaves ou substituição de cifras de fluxo, CTR_DRBG é muito mais rápido. Para usos de baixa vazão (geração de chaves de sessão, derivação de números únicos), a diferença de desempenho é insignificante. O OpenSSL 3.0 usa CTR_DRBG (AES-256) como padrão por esse motivo.

Na inicialização, os três mecanismos DRBG aceitam uma personalization_string opcional, que é combinada com a entrada de entropia para tornar a instância do DRBG única. Isso impede que dois mecanismos DRBG inicializados simultaneamente com a mesma entropia produzam a mesma saída — eles divergem com base na cadeia de personalização. Cadeias de personalização recomendadas: identificador da aplicação + ID do processo + ID da linha de execução + carimbo de data/hora + identificador de hardware. Mesmo que duas VMs recebam a mesma entropia (um problema de instantâneos de VM na nuvem), cadeias de personalização diferentes garantem fluxos diferentes de DRBG. A NIST SP 800-90C recomenda sempre usar uma cadeia de personalização. O parâmetro nonce tem uma finalidade semelhante: um valor curto e exclusivo que garante que nenhuma inicialização comece no mesmo estado que outra.

Os três mecanismos DRBG aceitam um parâmetro additional_input nas chamadas a Generate. Isso permite que o chamador injete contexto ou entropia adicionais em uma única chamada de geração, sem uma resemeadura completa. Usos: (1) injetar entropia por solicitação proveniente de uma fonte de entropia secundária; (2) fornecer contexto no nível da aplicação (ID da solicitação, carimbo de data/hora) para associar os valores gerados ao uso deles; (3) fornecer resistência à predição opcional, injetando entropia nova do sistema operacional. additional_input é incorporado ao estado do DRBG antes da geração da saída. Se additional_input fornecer entropia real, ele melhorará a segurança sem exigir uma resemeadura formal (que envolve a interface da fonte de entropia e a sobrecarga associada).

Depois que um DRBG deixa de ser inicializado (ou quando se muda para uma nova instância), o estado interno deve ser zerado com segurança. O estado V, C (Hash_DRBG), K, V (HMAC/CTR_DRBG) e todas as variáveis de trabalho intermediárias devem ser sobrescritos com zeros. Isso é chamado de zeragem explícita e é obrigatório nos módulos FIPS 140-3. No código C, use explicit_bzero() ou SecureZeroMemory() — uma chamada a memset otimizada pelo compilador pode ser removida como uma otimização de armazenamento morto, deixando material de chave na memória. A biblioteca zeroize do Rust e soluções semelhantes específicas de cada linguagem lidam com isso de forma portável. A destruição segura de chaves é importante em contextos nos quais despejos de memória, ataques de inicialização a frio ou ferramentas de inspeção de processos possam expor o estado residual.

O NIST fornece vetores de teste do Cryptographic Algorithm Validation Program (CAVP) para todos os mecanismos DRBG da SP 800-90A. Tipos de teste: (1) Testes de resposta conhecida (KATs) — dada uma entrada de entropia, um número único e uma cadeia de personalização fixos, verifique se a saída gerada corresponde aos valores pré-calculados. (2) Testes de resemeadura — verifique o estado do DRBG depois de uma operação de resemeadura. (3) Testes de PR (Prediction Resistance) — verifique se solicitar prediction_resistance=true produz a saída correta depois da injeção de entropia nova. A validação CAVP é obrigatória para a submissão à FIPS 140-3. Bibliotecas de código aberto (OpenSSL, mbedTLS) incluem vetores de teste CAVP em seus conjuntos de testes de regressão para detectar regressões nas implementações de DRBG.

As implementações de DRBG enfrentam riscos sutis de canais laterais além do modelo de segurança algorítmico. Ataques de temporização de cache contra o AES (em CTR_DRBG sem AES-NI) podem vazar material das chaves de rodada; o AES-NI elimina esse risco ao realizar os cálculos em registradores, sem consultas a tabelas. HMAC_DRBG usa HMAC internamente, que tem tempo constante se o SHA-256 subjacente também tiver tempo constante — o SHA-256 geralmente é considerado de tempo constante porque não possui ramificações dependentes de dados. Canais laterais físicos (análise de potência, radiação EM) contra hardware que produz DRBG são uma preocupação em cartões inteligentes e dispositivos da Internet das Coisas, sendo tratados por implementações com mascaramento. O ataque de cópia de segurança do estado: se um adversário conseguir ler o estado do DRBG por meio de uma vulnerabilidade de divulgação de memória (no estilo do Heartbleed), toda a saída futura ficará comprometida até a próxima resemeadura com entropia nova.

Se o estado de um DRBG for comprometido (por exemplo, por meio de uma vulnerabilidade de divulgação de memória), a recuperação exige: (1) Detectar o comprometimento — vazamentos do estado do DRBG não são evidentes por si só; é necessário monitoramento externo ou verificações de integridade. (2) Fazer uma nova semeadura com entropia nova proveniente de uma fonte confiável que não esteja envolvida no comprometimento. (3) Trocar as chaves de todo o material criptográfico derivado do DRBG comprometido (chaves de sessão e chaves de assinatura geradas desde a última resemeadura em estado íntegro). (4) Nas implementações de software, reiniciar o processo fornece uma inicialização limpa do DRBG. A SP 800-90C recomenda fontes de entropia encadeadas — se uma fonte for comprometida, a combinação ainda fornecerá segurança se a outra fonte fornecer entropia real.

Qual mecanismo de DRBG é mais rápido para gerar grandes volumes de saída pseudoaleatória em CPUs modernas?

Hash_DRBG usa hashing iterativo com Hash_df para derivação, produzindo saída por meio de laços H(0x01 || V). HMAC_DRBG usa HMAC como uma PRF com uma função Update de duas etapas (primeiro a chave, depois o valor), proporcionando uma redução de segurança clara. CTR_DRBG usa AES no modo contador com Block_Cipher_df, alcançando 5–10 GB/s em hardware com AES-NI. Todos aceitam personalization_string durante a inicialização para garantir a exclusividade da instância e additional_input a cada geração para associar contexto. Vetores de teste CAVP validam as implementações. O estado deve ser zerado com segurança depois do uso. O comprometimento do estado exige uma nova semeadura com entropia nova e a troca das chaves do material derivado.