Resumo

  • A RFC 9807 permite cadastrar e autenticar sem revelar a senha ao servidor; mesmo assim, o vazamento do registro e dos segredos relevantes de um servidor único ainda permite o inevitável ataque exaustivo offline contra aquela conta.
  • Chaves OPRF individuais podem nascer de uma única oprf_seed; sementes independentes, respostas simuladas, OPRF de limiar e recadastro mudam o raio de comprometimento, mas cobram novos custos operacionais.

Uma propriedade criptográfica pode ser verdadeira e ainda não ser um diagnóstico do sistema.

“O servidor nunca vê a senha” é uma descrição correta do OPAQUE. Ela não diz quem controla a raiz que deriva as chaves OPRF, se registros e chaves AKE compartilham o mesmo domínio de recuperação ou se milhões de contas podem abandonar uma configuração antiga no prazo de um incidente.

A RFC 9807, publicada em julho de 2025, especifica um PAKE aumentado. O cliente combina uma função pseudoaleatória obliviosa, um envelope de recuperação e uma troca autenticada de chaves. Ele demonstra conhecimento da senha e obtém uma chave de sessão comum sem entregar a senha, inclusive no cadastro.

A autoridade documental também tem limite. O registro do RFC Editor e o Datatracker classificam o texto como Informational no fluxo IRTF e expressão do consenso do Crypto Forum Research Group. O próprio documento afirma que não é produto do IETF nem padrão. O vínculo com o diretório IETF facilita descoberta; não transforma pesquisa em obrigação Standards Track.

O que saiu da fronteira do servidor

No login convencional, o TLS 1.3 protege o transporte e entrega a senha à aplicação. Depois da terminação, não impede registro acidental, exposição na memória ou encaminhamento impróprio. Canal seguro e receptor seguro são provas diferentes.

No OPRF da RFC 9497, o servidor detém a chave da função e recebe uma entrada cegada. O cliente obtém a saída; o servidor não aprende entrada nem saída. O cliente aplica o endurecimento e cria o envelope que protege seu material de autenticação.

O login usa KE1, KE2 e KE3. A autenticação explícita do cliente só se completa no terceiro passo. A emissão de KE2 não é sucesso. O recibo exige KE3 válido e conclusão de ServerFinish. A session_key é compartilhada; a export_key permanece com o cliente e só pode ser usada depois de autenticar o servidor. Nenhuma delas decide a autorização do negócio.

A adivinhação continua após a invasão

O trabalho original do OPAQUE preserva uma fronteira inevitável: em aPAKE com servidor único, o vazamento do arquivo e dos segredos correspondentes permite testar offline a senha do usuário afetado. O ganho é impedir uma tabela pré-calculada contra um mapeamento previsível. O agressor precisa esperar a violação e pagar por cada hipótese.

A KSF eleva esse custo. A RFC 9807 sugere configurações com Argon2id ou scrypt, e a RFC 9106 documenta Argon2. O cálculo, porém, ocorre no cliente. Mais memória e tempo prejudicam o atacante e também o celular básico, o equipamento embarcado e o fluxo de recuperação. O parâmetro só é defensável com latência, memória e falhas medidas na cauda da frota.

OPAQUE não elimina tentativas online, senhas fracas ou terminais comprometidos. Não torna uma invasão de servidor irrelevante. Ele evita que o servidor receba o segredo reutilizável, dificulta pré-computação, oferece autenticação mútua e sigilo futuro. A promessa fica mais forte quando não é ampliada além do modelo.

A raiz comum sob chaves por usuário

O servidor cria uma chave AKE e uma oprf_seed. A combinação da semente com um identificador único produz uma chave OPRF diferente por cliente. As folhas são individuais; a raiz pode ser comum.

A RFC 9807 recomenda uma semente compartilhada ao implementar sua mitigação de enumeração e também registra a consequência: se ela vazar, a segurança de todos os clientes que dependem dela fica comprometida. O rótulo “chave por usuário” não revela essa dependência transversal.

O estudo (Strong) aPAKE Revisited analisou a linhagem do rascunho em cenário multiusuário. O ataque não extrai todas as senhas apenas da semente. O arquivo comprometido de um usuário expõe a raiz; ela deriva a chave OPRF de outro; uma interação normal com o servidor fornece o material adicional para levar o teste desse segundo usuário ao modo offline. A RFC final cita a pesquisa e explicita o alcance.

Sementes independentes reduzem a raiz comum quando a aplicação não precisa da defesa de enumeração descrita. Em troca, a relação cliente-semente deve permanecer estável entre cadastro, login, réplica e restauração. Uma inconsistência pode revelar existência ou bloquear o titular. Distribuir segredos cria estado que também precisa ser governado.

A primazia do código em execução conduz à pergunta certa: não “a chave é individual?”, mas “qual administrador, processo, backup ou enclave consegue reconstruir quantas chaves?”.

Esconder a existência da conta é outro contrato

Para uma identidade inexistente, o servidor pode simular uma CredentialResponse. A masking_key, criada pelo cliente no cadastro, cifra a resposta para aproximar casos reais e falsos. Tamanho igual sem tempo e erro iguais ainda deixa um oráculo.

O cadastro não recebe essa proteção. Ele precisa distinguir identidade nova de já registrada e deve ser limitado ou restrito. A resposta simulada também pode virar superfície de abuso quando custa menos ao servidor do que a solicitação custa ao cliente.

A chave de mascaramento precisa de confidencialidade no cadastro. A RFC cita TLS e HPKE para acrescentar sigilo a um canal autenticado. A invisibilidade da senha não dispensa o cuidado com a cerimônia que instala os demais segredos.

A escolha de semente combina privacidade de existência, alcance transversal, consistência e custo. A abordagem de especificação mínima e decisão futura local é adequada: o protocolo fixa a interoperabilidade; o operador justifica localmente qual ameaça de enumeração merece qual arquitetura.

OPRF, AKE e registros exigem guardas distintos

oprf_seed, chave privada AKE e banco de RegistrationRecord dão poderes diferentes. A RFC permite manter a chave AKE não exportável em HSM. Separá-la pode impedir personificação do servidor após vazamento da semente e dos envelopes, mas não bloqueia os testes de senha habilitados por OPRF e registros.

O mapa deve mostrar quem avalia OPRF e para quantas contas, quem invoca AKE e quem copia registros vinculados a identidades. Três serviços sob o mesmo administrador e backup formam um cofre único.

Um OPRF de limiar mudaria a primeira fronteira: o agressor precisaria controlar participações suficientes ou continuar online. Separar servidores OPRF do servidor de autenticação também exige o banco de registros para o ataque offline. O artigo original admite o modelo, mas a RFC 9807 o deixa fora de escopo. Compatibilidade não prova custódia independente ou recuperação segura.

HKDF, hash para curvas da RFC 9380 e requisitos PAKE da RFC 8125 são componentes, não certificados da implementação inteira.

A migração só termina com recadastro

Alterar KSF, algoritmos ou material ligado ao RegistrationRecord, como a chave pública do servidor, exige novo cadastro. Trocar a senha também gera registro novo com aleatoriedade nova. A RFC torna explícito o custo que “agilidade criptográfica” costuma esconder.

Software novo não migra conta inativa, cliente antigo, recuperação falha ou dado dependente da export_key anterior. Com milhões de registros, a configuração vira dependência: sair do domínio antigo requer participação de usuário.

As camadas de realidade separam três fatos: versão implantada, registros migrados e segredo antigo retirado. O último só é verdadeiro quando nenhum registro ou fallback legado continua aceito.

O recibo deve listar elegíveis, novos registros, legados ainda válidos, inativos, falhas de recuperação, dispositivos incompatíveis com a nova KSF, dados ligados à antiga export key, uso de fallback e data em que ativos OPRF, AKE e registros anteriores deixaram de funcionar.

OPAQUE responde bem a uma pergunta delimitada: autenticar por senha sem entregá-la ao servidor e sem pré-computação reutilizável. A liderança erra quando transforma essa resposta em atestado geral.

A senha saiu da vista do servidor. O poder mudou para raízes de derivação, registros, operações privadas, simulação, capacidade do cliente e migração. Só um mapa verificável converte essa mudança em redução real de risco.

Sources