Resumo

  • A RFC 9106 especifica entradas, parâmetros e vetores de teste do Argon2 1.3; ela não certifica a capacidade de uma plataforma de autenticação.
  • A prova operacional precisa separar o custo de uma chamada da concorrência, do pico de memória, da fila, da resposta à sobrecarga e da população ainda presa a parâmetros antigos.

Uma solicitação de login chega ao verificador. O registro informa Argon2id, versão 19, sal exclusivo, 64 MiB de memória, três passadas e quatro lanes. A função termina corretamente. Ainda falta a pergunta que governa o serviço: o que acontece quando centenas dessas chamadas disputam memória ao mesmo tempo?

A própria RFC 9106 expõe esse limite. O procedimento de seleção pede primeiro a memória máxima que cada chamada pode consumir e o tempo que cada chamada pode levar. Em seguida, ajusta o número de passadas; se uma única passada já for lenta demais, reduz a memória. O parâmetro não é um selo abstrato. É uma escolha dentro de um envelope de recursos.

Esse envelope entra na computação. A senha P, o sal S, o paralelismo p, o tamanho do tag, a memória m, as passadas t, a versão e o tipo alimentam o hash inicial, junto com segredo e dados associados opcionais. A memória é organizada em blocos de 1 KiB e distribuída por p lanes. As lanes progridem em paralelo dentro de cada slice, mas sincronizam nas fronteiras. Passadas extras revisitam a matriz. Dizer apenas “usamos Argon2id” omite os valores que dominam o custo.

A especificação recomenda um sal de 16 bytes, exclusivo por senha. Ele impede que senhas iguais gerem o mesmo alvo reutilizável, mas não é secreto e não determina sozinho o trabalho de um palpite. O verificador precisa preservar versão e tupla de parâmetros por registro para validar e, depois, atualizar a credencial.

Duas recomendações uniformes mostram a troca. A primeira usa 2 GiB, uma passada e quatro lanes. A alternativa para memória restrita usa 64 MiB, três passadas e quatro lanes. O documento também apresenta exemplos em um processador de 2 GHz, incluindo autenticação de backend com quatro núcleos, oito lanes, 4 GiB e 0,5 segundo. São pontos de referência com hipóteses declaradas, não promessas para contêineres, máquinas virtuais, NUMA, alocadores, largura de banda ou caudas de latência.

Os vetores de teste são ainda mais estreitos. Eles permitem confirmar blocos intermediários e o tag final para entradas fixas, como 32 KiB, três passadas e quatro lanes. Passar no teste prova compatibilidade aritmética naquele caso. Não mede memória residente, cancelamento, limpeza, interferência do escalonador, crescimento de fila nem a conduta quando uma alocação falha.

É nessa lacuna que um hash forte no papel pode virar política frágil. Multiplicar 64 MiB pelo número de chamadas simultâneas produz um limite de planejamento, não uma observação. Overhead da biblioteca, reutilização do alocador e largura de banda alteram o resultado. O serviço deve decidir o comportamento no limite: enfileirar, rejeitar, limitar, expirar, retirar trabalho concorrente ou falhar fechado. Uma queda silenciosa para parâmetros baratos muda a alegação de segurança; deixar o processo esgotar recursos transforma o custo defensivo em arma de disponibilidade.

A migração cria outra ilusão. A orientação atual do NIST diz que esquema e fator de custo devem ser guardados com cada senha, permitindo aumentos futuros. Possibilidade não é conclusão. Um novo padrão pode cobrir somente senhas novas e contas que voltaram a entrar após a mudança. O controle real é a distribuição das tuplas armazenadas, o gatilho de rehash, as atualizações que falharam e a população residual verificada pelo orçamento antigo.

A conclusão sobre ataques também precisa de limites. A resistência de memória encarece palpites e força trocas entre tempo e espaço. Não revela a qualidade das senhas, o alcance de um vazamento, o hardware do adversário, o preço de energia nem o valor de uma conta. A RFC 9106 se identifica como produto Informational da IRTF, fora da Internet Standards Track, e adverte que resultados de pesquisa podem não ser adequados à implantação. Sua autoridade está na precisão do algoritmo, não na certificação de um sistema que ela nunca observou.

Isso separa este texto da cobertura da RFC 9807. O OPAQUE coloca uma KSF no cliente e traz questões de invisibilidade da senha, custódia da semente OPRF e migração de registros. Aqui o objeto é o verificador comum no servidor e o orçamento quando sal, memória, passadas e lanes viram muitas chamadas concorrentes. Um é mapa de protocolo e custódia; o outro é livro-caixa de capacidade e evidência.

O recibo operacional deve guardar tipo e versão exatos, política de sal, m, t, p, comprimento do tag e política de segredo opcional; biblioteca e classe de hardware; percentis quentes e frios; picos de memória por chamada e por processo; chamadas ativas; profundidade da fila; rejeições e timeouts; cancelamento e limpeza; pressão de CPU e banda; distribuição dos parâmetros; sucessos e falhas de rehash; limitação, recuperação e modo de falha. Um hash bem-sucedido é o começo desse encadeamento, não o fim.

Fontes

Especificação e status: RFC 9106, registro do RFC Editor, registro do IETF Datatracker e artigo do Argon2. Histórico: Password Hashing Competition. Requisitos do verificador: orientação de autenticadores do NIST e análise de senhas do NIST. Limite adjacente: RFC 9807. Estrutura analítica: Minimum Initial Specification, Reality Layers e Running-Code Primacy.