Resumo

  • O RFC 2104 combinou um hash existente com duas derivações da chave e dois preenchimentos fixos, preservando o código e o desempenho da função subjacente.
  • A troca do hash e o truncamento da saída faziam parte do desenho; algoritmo, chave, representação exata e tamanho da tag precisavam acompanhar qualquer veredito.
  • Uma tag correspondente não prova sozinha um emissor exclusivo, autorização, novidade, canonicalização, sigilo, entrega ou implementação correta.

O HMAC nasceu de uma escolha de engenharia pouco espetacular e muito durável: aproveitar aquilo que já funcionava. Em 1997, havia código rápido e amplamente disponível para hashes iterativos. O que faltava era uma maneira analisada de introduzir uma chave, sem exigir que cada protocolo inventasse sua própria mistura de segredo e mensagem.

O RFC 2104 entregou uma camada comum suficientemente rígida para interoperar e suficientemente fina para não confundir uma operação criptográfica com a política que viria depois dela.

A mesma função, em dois domínios separados

No RFC 2104, H é o hash, B é o tamanho de seu bloco de entrada e L é o tamanho da saída. Uma chave maior que B é primeiro reduzida por H; uma menor é completada com zeros. Dois blocos constantes separam as etapas: ipad repete 0x36 e opad repete 0x5c.

A fórmula é H((K xor opad) || H((K xor ipad) || text)). A mensagem entra na passagem interna após um bloco derivado da chave. O resumo interno entra na passagem externa após outra derivação. Nenhuma mudança na função de compressão de H é necessária.

Isso preservava desempenho, disponibilidade de código e simplicidade de chave, além de permitir análise e substituição do hash. Não definia, no entanto, a serialização da mensagem, a identidade do detentor da chave nem a consequência de uma verificação bem-sucedida.

Pré-calcular economiza trabalho e cria outro segredo

Uma implementação pode guardar os estados formados depois dos blocos interno e externo. Para mensagens pequenas, a economia de duas compressões por operação é relevante e não altera o resultado de outros participantes.

O documento exige que esses estados sejam protegidos como chaves. É uma fronteira operacional importante. Um derivado reutilizável pode conservar a capacidade do segredo mesmo quando o arquivo original continua inacessível. O controle precisa seguir a autoridade criptográfica, não apenas o nome do objeto armazenado.

Aleatoriedade, troca segura, proteção e renovação de chaves permanecem tarefas externas. O RFC as chama de ingredientes essenciais. A composição reduz improvisação; não corrige uma origem fraca de chaves nem uma custódia compartilhada além do necessário.

A tag autentica uma representação exata

Aplicações podem truncar o resultado e enviar apenas os t bits à esquerda. Essa decisão altera a resistência a tentativas de falsificação e pertence ao contrato do protocolo. Um registro útil precisa guardar algoritmo, identificador e época da chave, bytes autenticados e comprimento da tag, não somente a palavra “válido”.

HMAC trabalha com bytes, não com significados. Duas serializações de um mesmo objeto podem gerar resultados diferentes; duas partes também podem concordar perfeitamente sobre a representação errada. Ordenação de campos, codificação, espaços e normalização Unicode devem ser resolvidas antes. A tag não cria canonicalização depois do fato.

O uso de chave simétrica impõe outro limite. Todo detentor legítimo do segredo pode gerar uma tag correspondente. O resultado indica acesso à chave dentro daquele domínio, mas não distingue uma pessoa, máquina ou processo quando vários compartilham o mesmo material. Não é assinatura digital nem prova autônoma de não repúdio.

Vetores de teste transformaram a regra em interoperabilidade

O RFC 2202 reuniu casos para HMAC-MD5 e HMAC-SHA-1 ainda em 1997. Entradas e saídas conhecidas deram a implementações independentes uma referência executável. Era possível localizar divergências no tratamento de chaves longas, mensagens e truncamento sem discutir intenções abstratas.

O alcance desse recibo é específico. Passar nos vetores não cobre todo comprimento, erro, corrida, comparação temporal, seleção de chave ou estado de repetição. Confirma casos conhecidos da primitiva; não certifica o serviço inteiro.

A interface facilitou a troca, não executou a migração

Embora MD5 e SHA-1 aparecessem como exemplos, H era genérico. O RFC 4868 mais tarde definiu HMAC-SHA-256, HMAC-SHA-384 e HMAC-SHA-512 para IPsec. O RFC 6151 atualizou a avaliação de MD5 e rejeitou HMAC-MD5 em novos desenhos de protocolo.

A composição permaneceu; instâncias envelheceram. Essa agilidade ainda exigiu identificadores, negociação, código, testes, política e rotação de chaves. Uma boa abstração reduz dependências técnicas, mas não vence sozinha o custo e o incentivo para manter sistemas legados.

A adoção posterior no FIPS 198-1 do NIST mostra a expansão institucional do HMAC. Ela confirma a longevidade da estrutura, não a eternidade de cada algoritmo que a preencheu.

A comparação positiva não encerra a decisão

Uma mensagem antiga conserva uma tag matematicamente válida. Frescor exige nonce, contador, janela de tempo ou estado semelhante. Autorização exige associar o contexto autenticado a uma permissão. Sigilo exige criptografia. Entrega e efeito durável exigem recibos posteriores. Correção depende de implementação, testes e operação.

O legado do RFC 2104 foi uma peça comum com limites inteligíveis. Duas passagens tornaram o MAC reutilizável. A confiança continuou sendo responsabilidade do sistema ao redor.

Fontes