Radar Tech: a criptografia "aposentada" voltou a morder — chaves de CA de 512 bits caíram num desktop comum

Na segunda-feira, o engenheiro Matthew McPherrin publicou um experimento que deveria incomodar qualquer arquiteto: ele fatorou as chaves RSA de 512 bits de duas autoridades de certificação que o Netscape 4.51 embutiu em março de 1999 — a CA canadense E-Certify, "RSA Gold Server" (para SSL) e "RSA Gold Client" (para S/MIME), removida do navegador em 2002. Nada de cluster de laboratório: foram ~32 horas e ~29 horas num Ryzen 9 5950X desktop rodando CADO-NFS. Ou seja, com os primos recuperados, dá para reconstruir a chave privada e assinar certificados como se fosse 1999 (numa VM com relógio ajustado para antes de 16/10/2003).

O detalhe mais perturbador vem de um parágrafo do próprio autor: dias antes, alguém fatorou a RSA-260 (862 bits), a maior fatoração pública já feita. Para contexto, a RSA-155 — também de 512 bits — já havia caído lá em 1999. Mesmo na época, aquela chave era fraca demais para ter sido enviada como raiz de confiança da web.

Por que isso não é só nostalgia de engenharia reversa

Nenhuma CA moderna usa 512 bits, e ninguém roda Netscape 4.51. O alerta real não é "vamos reaver os anos 1990" — é sobre criptografia legada que ainda vive nos seus sistemas hoje:

• Uma intermediária de 1024 bits emitida por uma PKI interna há dez anos ainda assinando mTLS entre serviços.
• Um keystore de assinatura de código largado num segredo de CI, com a mesma chave desde 2015.
• TLS 1.0/1.1 ainda ligado num ERP ou numa integração de logística.
• Certificados de S/MIME ou CMS com SHA-1 cobrindo tráfego interno.

O 1024-bit foi deprecado pela Web PKI há mais de uma década; o 512-bit já era fraca quando nasceu, e a curva de custo de fatoração só desce. O padrão que o mercado aceita hoje — RSA ≥2048 bits ou ECC, assinatura ≥SHA-256, TLS ≥1.2 com TLS 1.3 preferencial — é o piso, não um luxo. E o futuro pós-quântico vai empurrar esse piso de novo, o que reforça a lição de sempre: o antigo não desaparece sozinho, ele fica incubando risco até alguém ter tempo e um CADO-NFS.

O que um arquiteto deveria fazer com isso

A notícia não pede um "fire drill". Pede que o time encare isso como uma decisão de arquitetura registrada, não como um checklist de fim de semana:

• Inventário primeiro. Você não pode aposentar o que não sabe que existe. Levante certificados de borda, PKI interna, keystores de build e trust stores de validação de código. Sem baseline, qualquer plano é chute.
• Defina o padrão-alvo e torne-o política — geração de chave em HSM/KMS (ou com CSPRNG verificada), emissão só de certificado moderno, e bloqueio de downgrade de versão/cifra para "compatibilidade".
• Migre em fases, com rollback. Nova CA/intermediária, rotação controlada, janela de convivência com timeout — e critério de saída mensurável para cada fase ("0 certificados <2048 bits em produção", "TLS 1.0/1.1 desligado").
• Registre como ADR, com drivers, alternativas e trade-offs — porque a próxima pessoa (ou o próximo auditor) precisa saber por que essa decisão existiu, e não apenas que ela foi tomada.

Foi exatamente a história de 1999 repetida em 2026 que transformamos num pacote pronto no ArchPrompts: um kit de 6 arquivos que leva o modelo a produzir um ADR de Crypto-Agility + roteiro de migração — com schema de saída rígido, guardrails contra inventário criado de forma alucinada, exemplos few-shot (incluindo o caso de quem não tem auditoria nenhuma) e um harness de verificação com critérios objetivos de aceite. Se o seu maior ativo criptográfico é "uma caixa de certificados que ninguém mexe desde 2011", o kit mapeia o caminho do inventário até o desligamento do legado — em pt-BR e pronto para o seu domínio.

Radar Tech é a curadoria diária de notícias de tecnologia com viés de arquitetura de software do ArchPrompts. Hoje: a fatoração de chaves RSA de CA de 512 bits dos anos 1990 e o que ela sinaliza sobre o risco de criptografia legada em produção.