Resumo

  • A RFC 10042, documento informativo do IETF assinado por Panos Kampanakis, Douglas Stebila e Torben Hansen, define três métodos SSH que combinam ML-KEM com P-256, P-384 ou X25519.
  • A resposta híbrida continua levando a chave pública do host e a assinatura do servidor. Depois, o protocolo de autenticação de usuário toma outra decisão; KEX, host e usuário não podem compartilhar o mesmo comprovante.
  • Um exemplo de SFTP da AWS registra separadamente o algoritmo híbrido, o algoritmo e a impressão digital da chave de host e, mais tarde, a autenticação do usuário por chave pública.

Uma sessão SSH termina com uma experiência simples: o prompt aparece ou a transferência começa. O caminho até esse resultado é menos simples e, para uma auditoria, essa complexidade é uma vantagem.

Primeiro, os dois lados escolhem como formar o segredo de transporte. Em seguida, o cliente avalia a identidade criptográfica do servidor. Só depois o servidor decide se o usuário indicado pode acessar o serviço. A palavra “chave” surge nas três fases, mas não designa a mesma credencial nem o mesmo proprietário.

A RFC 10042 fortalece a primeira fase. Publicada em agosto de 2026 na categoria Informational, ela define mlkem768nistp256-sha256, mlkem1024nistp384-sha384 e mlkem768x25519-sha256. Cada método reúne o segredo de ML-KEM com um segredo produzido por P-256, P-384 ou X25519.

O objetivo é proteger melhor contra a coleta de tráfego para decifração futura. Um invasor pode guardar sessões cifradas hoje e esperar por capacidade quântica capaz de quebrar o componente tradicional. A composição híbrida evita que a confidencialidade dependa de uma só família. É uma resposta importante, com um limite igualmente importante.

O host ainda precisa assinar

A própria mensagem do protocolo revela o limite. O cliente envia seus valores públicos efêmeros. O servidor devolve o ciphertext de ML-KEM e seu valor clássico, mas também inclui K_S, a chave pública do host, e uma assinatura sobre o hash do intercâmbio.

O segredo K é o hash da concatenação do segredo pós-quântico com o clássico. O hash do intercâmbio cobre as identificações de software, as duas mensagens de negociação, a chave de host, os valores híbridos e K. A assinatura usa a chave privada do host.

As operações estão ligadas pelo mesmo transcript, sem perder suas funções. O KEX produz material para as chaves de transporte. A assinatura associa o transcript a uma identidade de servidor. O cliente ainda precisa justificar por que aquela chave pertence ao destino esperado.

A RFC 4253 negocia kex_algorithms e server_host_key_algorithms em listas diferentes. O cliente pode consultar known_hosts, conferir uma impressão digital obtida por outro canal ou validar um certificado. Se aceitar a chave sem verificação, continua vulnerável a um atacante ativo. Nenhum cálculo de ML-KEM corrige uma decisão de confiança ignorada.

O comprovante do host deve guardar algoritmo, impressão digital ou certificado, origem da confiança, resultado da validação e rotação. O nome do KEX sozinho não preenche esses campos.

A credencial do usuário vem depois

Com o transporte protegido, a direção da avaliação muda. O servidor passa a verificar quem está pedindo acesso. A RFC 4252 define essa autenticação acima da camada de transporte. publickey é obrigatório para implementações; senha e hostbased são opcionais, e outros métodos podem ser adicionados.

Na autenticação por chave pública, o servidor recebe nome de usuário, serviço, algoritmo, chave e assinatura. Ele verifica se a chave é aceitável para a conta e pode exigir mais fatores antes de responder com sucesso.

Isso não repete a chave de host. A chave de host ajuda o cliente a reconhecer o servidor. A chave de usuário ajuda o servidor a reconhecer uma pessoa ou automação. authorized_keys, diretórios de identidade, contas suspensas, MFA, comandos forçados e permissões de SFTP pertencem a essa segunda direção.

É possível migrar KEX primeiro, assinaturas de host depois e credenciais de usuário em outro calendário. O erro não está no cronograma por etapas; está em transformar o primeiro marco em prova de conclusão dos demais.

Um log operacional com três resultados

Um artigo da AWS sobre SFTP híbrido oferece uma boa anatomia de evidência. O exemplo original, de 2023, usou nomes experimentais de Kyber. Uma atualização de 5 de setembro de 2025 afirma que duas políticas do AWS Transfer Family migraram para ML-KEM e lista os três nomes que seriam publicados na RFC 10042.

O log antigo não é uma sessão RFC 10042 e não deve ser apresentado como tal. Ele mostra, porém, a ordem das verificações: um KEX híbrido, ssh-ed25519 como algoritmo da chave de host, a impressão digital do servidor e, mais tarde, a autenticação por publickey. Só então a sessão SFTP é aberta.

Três perguntas reproduzem essa leitura:

  1. Qual método foi oferecido, selecionado e levado até SSH_MSG_NEWKEYS?
  2. Qual chave de host assinou e qual política levou o cliente a confiar nela?
  3. Qual método de usuário foi aceito, para qual conta e com quais limites?

“Conectado” comprova que um canal abriu. Não comprova que o usuário tinha o privilégio mínimo, que o arquivo foi cifrado em repouso, que a auditoria é completa ou que o backup pode ser restaurado sem exposição.

A passagem dos nomes experimentais para ML-KEM também evidencia o ciclo de vida. Clientes, servidores e scripts não atualizam juntos. Versão, ordem de preferência e fallback decidem o resultado de cada sessão. O registro da IANA marcado como SHOULD cria uma referência comum, não uma estatística mundial.

O mérito de padronizar apenas o necessário

A Amazon Science descreve Kampanakis como principal security engineer na AWS, com experiência em criptografia aplicada, automação de segurança e padrões. Em um perfil da AWS de 2023, ele recomendou inventariar criptografia assimétrica, testar efeitos em usos como SSH e preservar agilidade de algoritmo. Também destacou a diferença entre um protótipo controlado e suporte de longo prazo em escala.

Esse histórico oferece contexto, não autoria individual. Stebila e Hansen são coautores. O RFC reconhece implementação e revisão de participantes da AWS, OpenSSH, PuTTY e outros. O NIST padronizou ML-KEM; IETF e IANA mantêm as coordenadas do protocolo.

A RFC 10042 define um mínimo testável: mensagens, combinação de segredos, codificação de tamanho fixo, validação, chaves efêmeras por conexão, proibição de reutilizar a aleatoriedade do ciphertext e desconexão diante de entradas inválidas. É assim que a intenção vira interoperabilidade.

O princípio de Especificação Inicial Mínima de Heng Lu valoriza esse recorte. A norma compartilhada não precisa governar todo repositório de confiança, diretório de contas ou recuperação local. A Primazia do Código em Execução exige, por sua vez, registrar o que os sistemas fizeram.

Um recibo completo inclui versões, listas ofertadas, KEX escolhido, algoritmo e impressão digital do host, decisão de confiança, cifra e MAC, NEWKEYS, método de usuário, autorização, canal, rekey, fallback, falhas e limites da observação.

A RFC 10042 melhora a primeira coluna. Manter as outras duas separadas não reduz a conquista; impede que ela esconda a próxima tarefa.

Fontes