Resumo

  • RFC 3962 representava a contagem PBKDF2 em quatro octetos sem sinal, na ordem big-endian: 00 00 00 00 presente significava 4.294.967.296 iterações, enquanto a ausência do campo significava 4.096 depois de o KDC ter chance de fornecê-lo.
  • Uma contagem alta falsificada podia exaurir o cliente; uma baixa falsificada podia baratear a busca do invasor. A defesa dependia da procedência autenticada e de limites locais, não de um número mágico.

Há uma pergunta anterior a “qual é o valor?”: o valor veio no pacote? RFC 3962 fez dessa pergunta parte da segurança do perfil AES para Kerberos. Sem ela, um software poderia trocar 4.096 operações por mais de quatro bilhões apenas ao preencher um campo vazio com zeros.

O parâmetro de string para chave tinha quatro octetos e representava um inteiro sem sinal em ordem big-endian. Em geral, esse inteiro era a contagem de PBKDF2. O padrão totalmente zerado, porém, correspondia a 4.294.967.296, ou (2^{32}), iterações. Assim, um era o menor valor exprimível.

Quando o campo não era fornecido — depois de o KDC ter tido oportunidade de oferecê-lo — usava-se 00 00 10 00, decimal 4.096. O texto advertia que isso não recomendava 4.096 como política para o banco do Kerberos nem como palpite universal de pré-autenticação otimista. Era uma regra de interpretação de ausência, não um selo de adequação.

A presença fazia parte do valor

Bibliotecas costumam tratar zero como falso, omitir propriedades vazias ou aplicar um valor padrão durante a desserialização. Essas conveniências perdiam informação essencial aqui. A diferença entre ausente e quatro zeros multiplicava o trabalho por 1.048.576. Preservar o indicador de presença ao atravessar API, fila, cache e armazenamento era requisito de protocolo.

Publicado em fevereiro de 2005, RFC 3962 colocou AES dentro do arcabouço de RFC 3961. Definiu blocos de 128 bits, chaves AES de 128 ou 256 bits, CBC com ciphertext stealing e HMAC-SHA1-96. Os tipos de criptografia 17 e 18 e os checksums 15 e 16 permanecem no registro de parâmetros Kerberos da IANA. Registro comprova alocação, não ativação ou escolha em uma troca concreta.

A senha e o sal entravam no PBKDF2 para produzir uma chave temporária; a derivação de RFC 3961, com a constante kerberos, gerava a chave final. RFC 2898 era a referência contemporânea do PBKDF2 no PKCS #5, depois atualizada por RFC 8018. Uma saída AES-256 não atribui 256 bits de imprevisibilidade a uma senha humana. Iterar eleva o preço de testar cada hipótese, mas não inventa entropia.

O mesmo multiplicador cobrava dos dois lados

O fator de trabalho tornava cada tentativa mais lenta, inclusive a tentativa correta. Ele multiplicava o esforço de quem atacava por dicionário e o esforço do usuário legítimo pela mesma quantidade. Por isso, RFC 3962 não tratou a contagem como um placar em que mais sempre vence.

Uma resposta falsa atribuída ao KDC podia explorar o extremo superior. Ao anunciar uma contagem enorme, o invasor induzia o cliente a gastar CPU derivando uma chave errada. A implementação podia impor um teto contra negação de serviço; se impusesse, o RFC dizia que ele não deveria ficar abaixo de 50.000. Quatro bilhões de rodadas continuariam demoradas em máquinas rápidas, de modo que permitir interrupção também fazia sentido.

No extremo inferior, o golpe mudava de objetivo. Uma contagem pequena permitia ao adversário observar a resposta e testar candidatos com menos trabalho. Era razoável impor um piso. O controle completo combinava mínimo, máximo e confiança na origem; aceitar qualquer coisa da rede ou escolher sempre o maior número falhava por motivos diferentes.

Um evento que guarde somente iterations=4096 não resolve a investigação. O número pode ter vindo de mensagem autenticada, erro desprotegido, configuração local, cache, regra de campo ausente ou ambiente de teste. É preciso saber ainda se os limites foram aplicados antes do cálculo. Sem a linhagem, o mesmo valor descreve política, compatibilidade ou injeção.

Otimizar a viagem criava uma dívida de atualização

Na pré-autenticação otimista, o cliente tenta derivar a chave e mandar um timestamp protegido antes de buscar parâmetros atuais no KDC. Se acertar, economiza uma ida e volta. Sem informação complementar, contudo, só consegue adivinhar a contagem.

Nem o último valor conhecido era garantia. O RFC esperava que os sites elevassem o custo à medida que o hardware avançasse; uma observação de poucas horas antes poderia estar obsoleta. Em vez de fixar um padrão universal, recomendou configuração local dentro dos limites aceitos.

Essa passagem não eterniza números de 2005. Ela identifica uma responsabilidade: a contagem precisa de dono, data de observação e rota de atualização. Quando a otimização abre mão de consultar o KDC, substitui evidência fresca por política e deve declarar essa troca.

Calcular a chave não autorizava a operação

PBKDF2 concluído significa apenas que existe material de chave. RFC 4120 define tickets, autenticadores, frescor e replay no Kerberos V5. A derivação não prova isoladamente que a senha estava correta, que o KDC aceitou a pré-autenticação, que o ticket seguia válido ou que a aplicação permitiu a ação.

RFC 4537 separou tipos de criptografia oferecidos do tipo escolhido pelo servidor. RFC 6113 generalizou a pré-autenticação e o transporte de parâmetros. RFC 8009 criou perfis AES com HMAC-SHA2, e RFC 8429 desaconselhou algoritmos antigos. Cada documento mudou um elo sem transformar contagem, cadastro ou derivação em autoridade de aplicação.

O ciphertext stealing trazia outro limite independente. Ao dispensar expansão por padding, expunha o tamanho exato do texto original. Se o comprimento fosse sensível, a camada superior teria de escondê-lo. Aumentar o custo da senha não corrigia essa divulgação.

Uma trilha operacional deveria registrar presença do campo, quatro octetos originais, inteiro interpretado, origem e autenticidade da mensagem, piso e teto locais, tipo de criptografia, procedência do sal, versão da biblioteca, tempo, recursos, cancelamento e um resultado não secreto da derivação. Depois ligaria separadamente pré-autenticação, ticket, replay, autorização e resultado do serviço. Senha e chave secreta ficam fora dos logs.

O registro do RFC Editor, o histórico no Datatracker e a busca de errata documentam a especificação; a busca não mostrava ocorrências na captura. Isso descreve o prontuário do RFC, não garante implementações sem defeitos.

O legado de RFC 3962 não é mandar fazer bilhões de operações. É recusar uma equivalência cômoda: zero, ausência e padrão são fatos diferentes. Quando o sistema conserva essa diferença, consegue explicar o custo. Quando a apaga, perde também a cadeia de responsabilidade.

Fontes