Resumo

  • O RFC 9980 aceita o envio paralelo para chaves PQ/T e tradicionais como medida de transição, mas deixa claro que uma única rota tradicional impede a alegação de confidencialidade pós-quântica para aquela mensagem.
  • A governança deve observar o conjunto concreto de destinatários e de PKESKs emitidos, tratando cada exceção de compatibilidade como uma decisão nomeada.

Compatibilidade não é a mesma coisa que a propriedade prometida

Uma organização pode anunciar que possui uma chave ML-KEM-768+X25519. O anúncio não informa se o cliente a utilizou, se o destinatário a suporta, se ela foi escolhida para um dado envio ou se outro pacote permitiu abrir a mesma chave de sessão por um algoritmo tradicional. O padrão descreve interoperabilidade de chaves e pacotes; não emite atestado de operação.

Essa distinção aparece no desenho de migração. A Seção 8.1 permite que uma implementação cifre para chaves PQ(/T) e tradicionais a fim de evitar uma interrupção. Em OpenPGP, os vários PKESKs carregam alternativas de recuperação da mesma chave de sessão. A solução ajuda a entregar a mensagem, mas não apaga o caminho mais antigo. A Seção 3.1 diz que a confidencialidade não é pós-quântica se nem todas as chaves usadas tiverem suporte PQ(/T).

O ponto não é condenar a compatibilidade. Uma contraparte pode depender de um cliente ainda não atualizado; uma classe de comunicação pode ter um plano de continuidade específico. O ponto é impedir que uma exceção operacional vire uma conclusão criptográfica maior. Se um destinatário clássico fica no conjunto, alguém deve aceitar esse efeito para a classe de mensagem correspondente e explicar quando ele deixará de existir.

A forma do pacote decide o alcance da proteção

No esquema composto de RFC 9980, ML-KEM e um KEM ECDH participam de uma única chave PQ/T. Ambos produzem componentes que entram, com dados de vinculação de contexto, no cálculo da chave que envolve a chave de sessão. Não é apenas a coexistência de dois nomes de algoritmo: é uma construção específica, com verificações exigidas para a rota daquele destinatário.

Já colocar um PKESK tradicional ao lado de um PQ/T estabelece duas rotas para o mesmo segredo. A segunda não se transforma em componente do esquema composto. Uma revisão que apenas conte algoritmos “novos” pode perder o fato operacional decisivo: para quem esse conteúdo efetivamente pode ser decifrado. A unidade de avaliação é o envelope que saiu, não o catálogo de capacidades que a organização gostaria de ter.

Assinar e cifrar fazem transições diferentes

Para assinaturas, o RFC aceita outra acomodação. O remetente pode assinar com uma chave tradicional e outra PQ/T, pois verificadores antigos podem depender da primeira. Um verificador moderno pode aceitar ambas; se souber que o par já tem uma chave PQ/T e a ameaça quântica for relevante, pode preferir ignorar a assinatura tradicional. A escolha pertence ao contexto do verificador.

Nada disso prova identidade, mandato, intenção ou segurança do endpoint. Também não permite usar uma política de assinatura como substituta de uma política de destinatários. As duas superfícies têm objetos, incompatibilidades e consequências próprios.

Registrar sem vigiar o conteúdo

Uma prova proporcional pode guardar a classe da mensagem, as chaves selecionadas, versões, algoritmos, PKESKs emitidos, resultado de uma checagem de capacidade e a aprovação de uma exceção. A maioria das chaves PQ(/T) exige v6 ou posterior; ML-KEM-768+X25519 tem a exceção para subchaves v4 de ciframento. Os registros IANA para os IDs 30 a 36 ajudam a interpretar os pacotes, mas não demonstram adoção em campo.

Esse registro deve ser desenhado para provar a construção, não para acumular cópias de correio. Conteúdo, endereços e metadados de relacionamento exigem limites próprios. A decisão pode ser auditável sem que a migração se torne um novo mecanismo de vigilância.

Fontes