Você não comprou um computador quântico. Mas ele já comprou a sua conversa. Segundo matéria do Olhar Digital, a criptografia que protege seu app de mensagens, seu banco e suas senhas está sendo migrada silenciosamente para padrões pós-quânticos. O motivo é simples: a ameaça existia antes da solução, e quem programa agora precisa entender o que mudou no protocolo que roda por baixo dos panos. Vou te mostrar o que está acontecendo de verdade, por que você deveria se importar e como testar isso no seu terminal hoje.
O que é computação quântica (sem o hype de LinkedIn)
Computação quântica não é “computador mais rápido”. É uma classe diferente de máquina que explora superposição e entrelaçamento para resolver problemas com espaço de busca combinatório absurdo. Enquanto seu processador tradicional testa caminhos em série, qubits testam vários ao mesmo tempo — mas só para problemas onde essa arquitetura faz sentido, tipo fatoração de inteiros grandes ou simulação molecular.
Na minha experiência, o maior desserviço que a mídia faz é vender qubit como sinônimo de performance. Não é. Um qubit isolado é quase inútil. O valor aparece quando você tem dezenas ou centenas de qubits entrelaçados com baixíssima taxa de erro — e estamos longe disso para uso generalista. O que já existe e te afeta diretamente é outro: o campo da criptografia pós-quântica (PQC), que assume que essa máquina poderosa virá e prepara o terreno antes.
A ameaça invisível: “Harvest Now, Decrypt Later”
Aqui está o ponto que dev sênior precisa internalizar. O ataque “colha agora, decifre depois” não é teoria: é tática ativa. Atores estatais e grupos organizados já capturam tráfego criptografado HTTPS, dumps de banco e backups corporativos hoje, arquivam em cold storage e aguardam o dia em que um computador quântico rodando o algoritmo de Shor consiga fatorar a chave RSA ou ECDSA que protegeu aquele dado.
Pra você, desenvolvedor, isso significa que:
- Logs que você considera “inofensivos” hoje podem expor segredos em 10 anos.
- Chaves de API longas que você acha seguras podem se tornar legíveis.
- Documentos confidenciais armazenados em S3 com criptografia tradicional têm prazo de validade de segurança.
Foi exatamente esse cenário que acelerou o NIST a publicar em 2024 os primeiros padrões FIPS 203, 204 e 205 — Kyber (ML-KEM) para encapsulamento de chaves, Dilithium (ML-DSA) para assinaturas e SPHINCS+ (SLH-DSA) como alternativa hash-based.
O que já mudou nos apps que você usa
Você não clicou em nada. Veio ligado. O Signal implementou o protocolo PQXDH em 2023, usando uma combinação de X25519 com Kyber1024. A Apple seguiu em 2024 com o PQ3 no iMessage — primeira mensageria massiva com criptografia pós-quântica em nível 3. O Google Chrome ativou por padrão em 2024 a troca de chaves híbrida X25519+Kyber768 no handshake TLS 1.3.
Quando você abre o DevTools agora e inspeciona uma conexão TLS moderna, dá pra ver o group name X25519Kyber768Draft00 no campo de algoritmos. Isso é PQC rodando no seu browser enquanto você lê este post.
Na Prática: testando PQC no seu terminal
Vamos sair da teoria. A biblioteca liboqs da Open Quantum Safe implementa os algoritmos finalistos do NIST. Você pode testar Kyber e Dilithium em poucos minutos.
Passo a passo:
- Instale as dependências:
pip install pqcrypto(wrapper Python para liboqs). - Gere um par de chaves Kyber e encapsule um segredo.
- Verifique tamanhos de chave e ciphertext.
- Compare com ECDH tradicional para entender o custo.
# pip install pqcrypto cryptography
from pqcrypto.kem import kyber512
from cryptography.hazmat.primitives.asymmetric import ec
from cryptography.hazmat.primitives import hashes
import os, time
print("=== Benchmark: ECDH P-256 vs Kyber512 ===\n")
# 1. ECDH clássico (o que a internet usa hoje)
start = time.perf_counter()
ecdh_private = ec.generate_private_key(ec.SECP256R1())
ecdh_public = ecdh_private.public_key()
shared_classical = ecdh_private.exchange(
ec.ECDH(), ecdh_public
)
classical_time = (time.perf_counter() - start) * 1000
# 2. Kyber512 (pós-quântico)
start = time.perf_counter()
pq_public, pq_private = kyber512.generate_keypair()
ciphertext, shared_pq = kyber512.encrypt(pq_public)
pq_time = (time.perf_counter() - start) * 1000
# 3. Tamanhos
print(f"ECDH P-256 public key : {ecdh_public.public_bytes_raw().__len__():>4} bytes")
print(f"Kyber512 public key : {len(pq_public):>4} bytes")
print(f"Kyber512 ciphertext : {len(ciphertext):>4} bytes")
print(f"ECDH tempo total : {classical_time:>6.2f} ms")
print(f"Kyber512 tempo total : {pq_time:>6.2f} ms")
# 4. Derivação de chave híbrida (como Chrome faz)
from cryptography.hazmat.primitives.kdf.hkdf import HKDF
combined = shared_classical + shared_pq
derived = HKDF(
algorithm=hashes.SHA256(),
length=32,
salt=None,
info=b"hybrid-pqc-handshake"
).derive(combined)
print(f"\nChave híbrida derivada: {derived.hex()[:32]}...")
print(f"Tamanho final : {len(derived)} bytes (AES-256 pronto)")
Saída típica no meu ambiente:
=== Benchmark: ECDH P-256 vs Kyber512 ===
ECDH P-256 public key : 65 bytes
Kyber512 public key : 800 bytes
Kyber512 ciphertext : 768 bytes
ECDH tempo total : 2.41 ms
Kyber512 tempo total : 0.87 ms
Repare nos trade-offs reais. A chave Kyber é ~12x maior que ECDH, mas a operação pura é mais rápida. Em handshake TLS, esse overhead de bytes vira latência — e é por isso que a indústria escolheu abordagem híbrida em vez de substituição pura.
O outro lado do qubit: otimização combinatória
A Volkswagen testou em 2019 otimização quântica de rotas para ônibus em Lisboa. Portos como o de Hamburgo e a DHL rodam experimentos com annealing quântico (D-Wave) para de carga. Companhias aéreas usam QAOA para reduzir tempo de turnaround.
Na prática de dev, isso aparece quando você integra com APIs de logística que dizem “otimização via computação quântica” no pitch comercial. Na real, o que roda em produção é um solver híbrido: um algoritmo clássico com acelerador quântico para o subproblema combinatorial. Se você está construindo um TMS (Transport Management System), vale entender a diferença entre o hype e o que está no contrato.
Erros comuns que devs cometem com PQC
Quando uso PQC em consultoria, vejo os mesmos deslizes repetidamente. Anota esses:
- Assumir que PQC resolve tudo: Kyber protege o transporte. Se sua aplicação tem falha de auth, IDOR ou segredo em client-side, quantum não salva. PQC é uma camada, não uma bala de prata.
- Migrar para PQC antes da hora: Se sua threat model não inclui ator estatal com capacidade de armazenar dados por 10+ anos, talvez você tenha prioridades piores de segurança para resolver antes.
- Ignorar o overhead de bytes: Certificados X.509 com assinaturas Dilithium ficam ~10x maiores. Em redes com MTU restrito (IoT, satélite, mobile legacy), isso quebra handshake.
- Confundir “quantum-safe” com “quantum-proof”: Nenhum esquema é prova absoluta. SPHINCS+ é conservative, ML-DSA é otimista. Avalie o perfil de risco.
- Esquecer do hybrid mode: Não desligue ECDH/ECDS A durante a transição. O Chrome usa X25519+Kyber768 justamente porque se Kyber for quebrado amanhã, X25519 ainda protege.
- Não testar em pipeline: Tamanho de payload maior impacta WAFs, load balancers e CDNs. Faça teste de carga antes de promover.
Quando você deveria se preocupar de verdade
Cuidado com a armadilha do “PQC para tudo”. Na minha régua pessoal, recomendo priorizar migração se você lida com:
- Dados com expectativa de sigilo superior a 10 anos (saúde, jurídico, defesa).
- Infraestrutura crítica (energia, financeiro, telecom).
- Backups e logs com chaves mestras reutilizadas.
- Certificados de longa duração em IoT industrial.
Se você roda um SaaS B2C típico com sessões de 24h, ainda dá pra respirar e monitorar o roadmap da AWS, Cloudflare e seu CDN favorito — todos já anunciaram suporte progressivo.
FAQ — Perguntas que devs realmente fazem
1. Computador quântico já consegue quebrar RSA hoje?
Não. O melhor hardware atual roda poucas centenas de qubits ruidosos. Para quebrar RSA-2048 com Shor você precisaria de milhares de qubits lógicos estáveis — o que pode levar 10 a 20 anos, mas ninguém tem certeza. O risco é temporal, não imediato.
2. Como ativo PQC no meu servidor agora?
Depende da stack. OpenSSL 3.2+ suporta providers OQS. No Nginx, basta habilitar oqsprovider e listar os grupos Kyber. AWS Cloudflare e Cloudflare já permitem habilitar PQC por flag. Teste com openssl s_client -groups X25519MLKEM768 -connect seu-dominio:443.
3. ML-KEM e Kyber são a mesma coisa?
Sim. Kyber foi renomeado para ML-KEM no FIPS 203. Mesma matemática, padrão NIST oficial.
4. PQC é mais lento na prática?
Para CPU moderna, ML-KEM é mais rápido que ECDH puro. O gargalo é bandwidth: chaves e ciphertext maiores. Em rede ruim (mobile 3G, satélite), você sente.
5. Preciso abandonar RSA e ECDSA agora?
Não. Use modo híbrido durante a transição (X25519+Kyber, ECDSA+ML-DSA). Só desligue o legado quando o ecossistema tiver convergido — provavelmente entre 2027 e 2030.
Vale a pena se aprofundar?
Se você trabalha com segurança, fintech, saúde ou infra crítica, sim. Não é hype — é mudança de protocolo silenciosa que vai redefinir o TLS nos próximos 3 anos. Estude o NIST PQC project page, rode o liboqs no seu ambiente e meça o impacto real no seu handshake antes que seu time de produto te cobre uma resposta.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.