Crypto Agility 2.0 · Beta · Gate β

Troca de algoritmo sem reescrever a app

Um registry central de 11 algoritmos + motor de políticas + negociação dinâmica. Quando um algoritmo cai, rodamos pelo heartbeat, não por hotfix.

Beta honesto: registry, policy engine, negotiation, migration e audit log estão em produção. Falcon e SPHINCS+ estão reservados (flag implementationAvailable:false) até pqsl-core v3.1/v3.2. A certificação FIPS de módulo está em curso — não é claim atual.

Ver registry público (JSON)Calendário de depreciação enterprise →

O que é crypto-agility (sem buzz)?

Crypto-agility é a capacidade de trocar o algoritmo criptográfico de uma aplicação sem reescrever código, sem downtime forçado e sem perder dados cifrados no caminho. Soa trivial, mas a maioria dos sistemas tem o algoritmo hardcoded: no dia em que a NIST avisar que Dilithium2 é quebrado, cada engineer corre por uma semana a trocar strings no código.

A arquitectura da PosQuantum transforma o algoritmo num registo da base de dados. Cada primitiva (KEM, DSA, AEAD, Hash) tem slug versionado. A aplicação nunca referencia "kyber768" diretamente — pergunta ao servidor qual o algoritmo aceite e usa-o. Quando muda, muda para todos.

Isto é crítico para o mundo pós-quântico porque vamos ter múltiplas migrações: Dilithium → Falcon em alguns casos, SPHINCS+ como backup hash-based, eventual Dilithium2 para Dilithium3, híbrido → puro PQ quando confiança for suficiente. Não é um evento — é um processo contínuo.

Os 11 algoritmos no registry

Snapshot do que está catalogado hoje. O JSON canónico vive em GET /api/crypto/algorithms — sem auth necessária.

Slug	Família	NIST	Estado	Pref.	Impl.	Notas
kyber768-x25519-hybrid-v1	hybrid-kem	L3	active			KEM híbrido (Kyber768 + X25519) — preferido. Combina PQ e clássico em cascata para defesa em profundidade.
kyber768-v1	kem	L3	active	—		ML-KEM-768 (Kyber) puro — FIPS 203, sem fallback clássico.
kyber1024-x25519-hybrid-v1	hybrid-kem	L5	active	—		Variante híbrida de nível 5 (Kyber1024 + X25519) para cenários ultra-sensíveis.
kyber1024-v1	kem	L5	active	—		ML-KEM-1024 (Kyber) puro — FIPS 203, nível 5.
dilithium3-v1	dsa	L3	active			ML-DSA-65 (Dilithium3) — preferido. Assinatura digital pós-quântica FIPS 204.
dilithium5-v1	dsa	L5	active	—		ML-DSA-87 (Dilithium5) — nível 5, FIPS 204.
falcon512-v1	dsa	L1	active	—	reserved	Falcon-512 — assinatura compacta. Reservado no registry; implementação em pqsl-core v3.1+.
sphincs-shake-128f-v1	dsa	L1	active	—	reserved	SPHINCS+ SHAKE 128f — hash-based, sem reliance em lattice. Reservado; implementação em pqsl-core v3.2+.
ed25519-v1	classical-dsa	L1	deprecated	—		Ed25519 — assinatura clássica. Depreciado em 2026-04-01 (sem data de remoção anunciada).
x25519-v1	classical-kem	L1	active	—		X25519 — ECDH clássica. Usado apenas em modo híbrido (nunca isoladamente).
aes-256-gcm-v1	aead	L5	active			AES-256-GCM — AEAD simétrico. Sobrevive ao quantum (Grover exige 2×chave).

Como funciona — 5 passos

Do registry ao audit log, sem nada escondido.

Registry

Catálogo central de algoritmos na base de dados. Cada algoritmo tem slug, família, nível NIST, estado, flags.

Policy

Política global + per-customer: nível mínimo NIST, algoritmos banidos, clássicos aceites ou rejeitados.

Negotiate

Cliente envia candidatos. Servidor aplica política e escolhe o conjunto conforme (kem+dsa+aead).

Migrate

Ao depreciar algoritmo, servidor marca pendingAlgorithmRotation. Agent/cliente roda no próximo heartbeat.

Audit

Cada negociação, mudança de política, depreciação e rotação é gravada em CryptoEvent com origem IP.

6 decisões arquitecturais (e porquê)

Cada decisão foi debatida e documentada antes do código. Sem marketing — só trade-offs.

Ed25519 entra como deprecated

Não como "ativo" num primeiro dia cego. Honestidade: o mercado precisa de tempo, mas o aviso é imediato.

Default rejeita clássico puro

Customer tem de fazer opt-in explícito em allowClassicalFallback. Sem surpresas.

Rotação eager no heartbeat

Servidor marca pendingAlgorithmRotation; agent/cliente roda no próximo heartbeat. Não esperamos janela de manutenção.

Negociação requer API Key

GET /algorithms é público (transparência). POST /negotiate requer customer API key (auditabilidade + rate-limit).

Política global + override por cliente

MVP direto: uma política global + overrides opcionais. Hierarquia de policies fica para Gate γ se necessário.

Drive Guard rotation separada agora

A rotação de wrapKey do Drive Guard continua no seu fluxo dedicado. Unificação completa em Gate γ.

O que ainda não faz — e quando fará

Esta secção existe porque "crypto-agility" é um termo abusado pelo marketing. Aqui está o que falta para ser honesto.

FIPS 140-3 de módulo: em curso

A flag fipsCompliant:true significa que os crates implementam FIPS 203/204. A certificação de módulo (hardware ou software) está em Q3 2026. Não chamamos "FIPS-certified" antes de termos o certificado CMVP.

Falcon e SPHINCS+: reservados

Ambos aparecem no registry com implementationAvailable:false. Só negociaremos assinatura Falcon ou SPHINCS+ depois de pqsl-core v3.1 e v3.2. Estão no registry para o pipeline de migração — não para uso hoje.

Negociação é a nível aplicação, não TLS

O endpoint /api/crypto/negotiate é HTTP sobre TLS clássico. A negociação de KEM/DSA/AEAD acontece no payload para decidir que primitivos usar dentro da aplicação. Post-quantum TLS handshake está fora do escopo desta fase.

Rotação nem sempre é zero-downtime

Para Drive Guard, a rotação de wrapKey exige o agent online. Se o dispositivo estiver offline, fica em pendingAlgorithmRotation até o próximo heartbeat. Para PUCE archives novos, aplica-se automaticamente.

Sem HSM na MVP

As chaves do customer estão cifradas na DB (AES-256-GCM com chave da app). HSM / KMS externo (CloudHSM, YubiHSM) fica para Gate γ — vamos anunciar quando estiver integrado.

Depreciação Ed25519 sem data de remoção

Marcamos Ed25519 como deprecated a 2026-04-01 para avisar o mercado. Não anunciamos removedAt porque seria um prazo fictício — remoção dependerá da maturidade dos substitutos (Dilithium3 é o default) e da adoção dos customers.

Para developers

2 endpoints públicos. Autenticação só onde faz sentido auditar.

GET /api/crypto/algorithms

Listagem pública do registry. Sem auth. Rate-limit 100/min por IP.

$ curl https://posquantum.com/api/crypto/algorithms
{
  "algorithms": [
    {
      "slug": "kyber768-x25519-hybrid-v1",
      "family": "hybrid-kem",
      "nistLevel": 3,
      "status": "active",
      ...
    }
  ]
}

POST /api/crypto/negotiate

Customer API key obrigatório. Rate-limit 60/min por customer. Loga em CryptoEvent.

$ curl -X POST .../negotiate \
  -H "Authorization: Bearer pq_live_..." \
  -d '{
    "candidates": {
      "kem": ["kyber768-x25519-hybrid-v1"],
      "dsa": ["dilithium3-v1"],
      "aead": ["aes-256-gcm-v1"]
    }
  }'
→ { "ok": true, "selected": { ... } }

Auditabilidade total

Tudo o que o módulo faz fica num log estruturado (CryptoEvent): cada negociação, cada mudança de política, cada depreciação agendada, cada flag de rotação. Campos: timestamp, customerId, userId, actorType, eventType, algorithmSlug, metadata (JSON), originIp.

Ver página de auditoria Console admin (login)

Calendário de depreciação dedicado

Enterprise customers recebem calendário privado de depreciação com 12 meses de antecedência, policies por-tenant e slot em comités técnicos sobre substituição de Falcon/SPHINCS+. Fala com o time.

Falar com o time