## Capítulo 20 — Segurança quântica e pós-quântica: casos fundamentais ### Mapa da aula Aula 20 publicada. Mapa, exemplo, EX039. ```mermaid flowchart TD N0["20.1 O Shor e as estimativas de recursos"] N1["20.2 Candidatos quebrados"] N2["20.3 Falhas de implementação"] N3["20.4 Implantação inicial"] N4["20.6 Atividade prática"] N5["Síntese"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 N5 --> EX["Exemplo resolvido"] EX --> Q["Exercício EX039"] ``` ### Desenho lógico ```mermaid flowchart LR N0["20.1 O Shor e as estimativas de recursos"] N1["20.2 Candidatos quebrados"] N2["20.3 Falhas de implementação"] N3["20.4 Implantação inicial"] N4["20.6 Atividade prática"] N5["Síntese"] N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX039"] ``` ```text [20.1 O Shor e as estimativas de recursos] | v [20.2 Candidatos quebrados] | v [20.3 Falhas de implementação] | v [20.4 Implantação inicial] | v [20.6 Atividade prática] | v [Síntese] | v [Exemplo resolvido] --> [Exercício EX039] ``` ### Objetivos de aprendizagem Você vai (1) resumir os casos públicos que moldaram a prática pós-quântica; (2) explicar o que cada caso ensina sobre evidências e hipóteses; (3) relacionar os casos com a implantação híbrida; e (4) aplicar as suas lições às decisões da HCU. ### 20.1 O Shor e as estimativas de recursos O algoritmo de Shor de 1994 (versão em periódico de 1997) mostrou que a fatoração e os logaritmos discretos são resolvíveis de forma eficiente num computador quântico. Por décadas, a questão foram os recursos. Gidney e Ekerå (2021) estimaram 20 milhões de qubits ruidosos funcionando por oito horas para fatorar o RSA-2048; Gidney (2025) baixou isso para menos de um milhão de qubits ruidosos em menos de uma semana, sob hipóteses declaradas sobre as taxas de erro e a conectividade. A lição: as estimativas de recursos caem à medida que os algoritmos e a correção de erros melhoram, então os planos não podem depender de que a estimativa de hoje permaneça fixa. O plano da HCU usa, portanto, uma faixa de datas de chegada, e não um único número. ### 20.2 Candidatos quebrados O processo do NIST eliminou candidatos publicamente. O Rainbow, uma assinatura multivariada, foi quebrado por Beullens (2022) com um ataque de recuperação de chave que rodava "num fim de semana num laptop". O SIKE, um KEM baseado em isogenias, foi quebrado por Castryck e Decru (2022) com um ataque clássico. Os dois haviam sobrevivido a anos de análise. A lição: os esquemas novos carregam o risco de quebras clássicas, o que é um argumento central para a implantação híbrida — combinar um algoritmo pós-quântico e um tradicional, para que um atacante precise quebrar os dois. Nenhuma das quebras precisou de um computador quântico. ### 20.3 Falhas de implementação O KyberSlash (Bernstein et al., 2024) mostrou que várias implementações do Kyber vazavam informações secretas pelo tempo das operações de divisão, embora a matemática fosse sólida. A lição: uma norma correta não é uma implementação correta; use bibliotecas verificadas e mantenha-as atualizadas. Para a HCU, a lição virou uma pergunta de compras: qual biblioteca e qual versão cada equipamento usa, e com que rapidez o fornecedor entrega as correções? Um fornecedor que não consegue responder é um risco, qualquer que seja o algoritmo que ele alega suportar. ### 20.4 Implantação inicial A equipe do Chrome, do Google, anunciou em 2023 a troca de chaves híbrida pós-quântica ([Chromium Blog](https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html)), e alguns servidores e middleboxes falharam diante do ClientHello maior. A lição: a implantação expõe bugs do ecossistema que nenhuma revisão de especificação encontra; a implantação em estágios e o monitoramento são essenciais. A maioria das falhas veio de software que supunha que as mensagens de handshake continuariam pequenas. Os navegadores implantaram gradualmente, mediram as falhas e trabalharam com os operadores de servidores para corrigi-las. A HCU segue o mesmo padrão em escala menor, com as suas agências piloto. ### 20.5 Exemplo resolvido O fornecedor da HCU propõe ativar imediatamente o ML-KEM puro nas VPNs das agências. Aplicando os casos: o SIKE mostra que um esquema novo pode falhar de repente, então um híbrido com ECDH é o projeto de transição prudente; o KyberSlash mostra que a versão da implementação do fornecedor importa, então a HCU pergunta qual biblioteca e qual versão o equipamento usa; a experiência do Chrome mostra que uma agência com um dispositivo legado pode quebrar, então a HCU começa com três agências piloto. Cada agência piloto é monitorada quanto a fallbacks e falhas de handshake antes que qualquer implantação mais ampla seja aprovada. ### 20.6 Atividade prática Escreva um cartão de lição de meia página para um dos quatro casos: o que aconteceu, a fonte primária, o que ele mudou na prática e uma pergunta que ele levanta para a HCU. Um bom cartão é curto o bastante para ser lido em um minuto e aponta para a fonte primária, e não para um resumo dela. A mudança prática deve ser específica, como a passagem para projetos híbridos ou testes de tempo mais rigorosos. A sua pergunta para a HCU deve ser uma que a equipe realmente consiga responder, por exemplo quais produtos dos seus fornecedores ainda usam uma versão vulnerável de biblioteca. ### 20.7 Erros comuns e limites - Concluir a partir do SIKE que toda a PQC é frágil; o ML-KEM se apoia numa família de problemas diferente e bem estudada. - Tratar as estimativas de recursos como previsões de datas. - Supor que uma norma final implica implementações seguras. O SIKE e o Rainbow foram quebrados pelas suas próprias estruturas; os problemas de reticulados do ML-KEM têm uma longa história de pesquisa e resistiram à análise. Isso é evidência, e não demonstração, e é por isso que se usam híbridos durante a transição. As estimativas de recursos mostram do que um algoritmo precisaria, e não quando alguém vai construí-lo. As implementações precisam de revisão e testes próprios, como o KyberSlash mostrou para um projeto sólido. ### Exercícios - **EX039 — Do caso ao controle.** Associe cada um dos quatro casos a um controle que a HCU deveria adotar. Rubrica: 3 = quatro associações plausíveis e distintas. - **EX040 — Tendência das estimativas.** Explique por que a queda das estimativas de recursos deve mudar o planejamento de *y* (tempo de migração) na desigualdade de Mosca, e não apenas o de *z*. Rubrica: 3 = defende começar mais cedo e construir agilidade. ### Síntese A queda das estimativas de recursos, os candidatos quebrados, as falhas de implementação e os bugs de implantação ensinam, cada um, um controle: planejar para a incerteza, implantar híbridos, usar bibliotecas verificadas e implantar em estágios. ### Continue estudando — capítulo 20 de 40 [← Capítulo 19](#ch-19) · [Índice de capítulos do curso](../SUBJECTS.md) · [Capítulo 21 →](#ch-21) Siga para a próxima lição escrita. ## Worked answers **EX039.** Queda das estimativas → planejar com cronogramas variados e começar cedo. Rainbow/SIKE → implantação híbrida. KyberSlash → bibliotecas verificadas e atualizadas e acompanhamento das versões. Implantação do Chrome → implantação em estágios com monitoramento. **EX040.** Se *z* puder ser menor que o esperado, a única variável que a HCU controla é *y*. Começar mais cedo e construir agilidade reduz *y* nesta migração e nas futuras, mantendo *x* + *y* abaixo de uma faixa mais ampla de *z*.