Post-Quantum Crypto (Kyber + Dilithium)
A partir da v4.5, o CipherVault expõe API para criptografia pós-quântica usando algoritmos NIST aprovados:
- Kyber KEM (FIPS 203) — Key Encapsulation Mechanism
- Dilithium signatures (FIPS 204) — assinatura digital
Implementação via @noble/post-quantum.
Por que PQC
Adversários gravando tráfego cifrado hoje podem decifrar amanhã quando computadores quânticos suficientemente grandes existirem (estimativas para 2030-2040, com riscos ofensivos para dados de longa duração).
Casos de uso pra PQC já em 2026:
- Dados com retenção > 10 anos (registros médicos, financeiros, classificados)
- Comunicações com assinatura de longo prazo (PKI, código assinado)
- Estados-nação como threat model
- Compliance NIST/FIPS quando se torna mandatório
Endpoints
Kyber KEM
POST /pqc/kem/encapsulate Gera par {ciphertext, shared_secret} a partir de public key
POST /pqc/kem/decapsulate Recupera shared_secret a partir de ciphertext + private key
POST /pqc/kem/keygen Gera keypair (alice's keypair)
# 1. Alice gera keypair
curl -X POST https://cv.acme.com.br/pqc/kem/keygen \
-H "Authorization: Bearer $CV_TOKEN"
# → { "public_key": "...", "private_key": "..." } (private nunca persiste no CV)
# 2. Bob encapsula com a pubkey da Alice
curl -X POST https://cv.acme.com.br/pqc/kem/encapsulate \
-d '{ "public_key": "<alice_pub>" }'
# → { "ciphertext": "...", "shared_secret": "<32 bytes b64>" }
# 3. Alice decapsula
curl -X POST https://cv.acme.com.br/pqc/kem/decapsulate \
-d '{ "ciphertext": "<bob_ct>", "private_key": "<alice_priv>" }'
# → { "shared_secret": "<32 bytes b64 — same as Bob's>" }
Dilithium signatures
POST /pqc/sig/keygen Gera keypair
POST /pqc/sig/sign Assina mensagem
POST /pqc/sig/verify Verifica assinatura
curl -X POST https://cv.acme.com.br/pqc/sig/sign \
-d '{ "message": "Rafael Martinez 2026", "private_key": "..." }'
# → { "signature": "..." }
curl -X POST https://cv.acme.com.br/pqc/sig/verify \
-d '{ "message": "Rafael Martinez 2026", "signature": "...", "public_key": "..." }'
# → { "valid": true }
Modo híbrido (recomendado para 2026+)
Combina algoritmo clássico (RSA/ECDSA) com PQC. Quebra de um deles não compromete — atacante precisa quebrar ambos.
POST /pqc/hybrid/sign
POST /pqc/hybrid/verify
POST /pqc/hybrid/encrypt
POST /pqc/hybrid/decrypt
curl -X POST https://cv.acme.com.br/pqc/hybrid/sign \
-d '{
"message": "audit-event-2026-05-12",
"classical_alg": "ed25519",
"classical_private_key": "...",
"pqc_private_key": "..."
}'
# → { "signature": "<concat: classical_sig + ':' + pqc_sig>" }
Parâmetros de algoritmo (defaults)
| Operação | Algoritmo | Tamanho |
|---|---|---|
| KEM | ML-KEM-768 (Kyber-768) | pub 1184B / priv 2400B / ct 1088B |
| Sig | ML-DSA-65 (Dilithium-3) | pub 1952B / priv 4032B / sig 3309B |
Maior segurança (ML-KEM-1024, ML-DSA-87) via query param
?level=high.
Performance
- Kyber-768 encapsulate: ~50µs (Node 20, AMD EPYC)
- Kyber-768 decapsulate: ~70µs
- Dilithium-3 sign: ~300µs
- Dilithium-3 verify: ~150µs
10-100× mais lento que ECDSA/Ed25519 mas ainda absolutamente prático para uso operacional.
Storage no CV
Por design, o CV não persiste private keys PQC — apenas processa em
memória, devolve para o cliente, esquece. App é responsável por
armazenar a private key (idealmente em outro vault do CV como
fortress).
Public keys podem ser registradas em vaults regulares para distribuição.
PQC V2 — Hybrid wrap + Dual-sign + KMIP PQC (v4.8)
A v4.8 adiciona 5 expansões sobre PQC V1:
Hybrid-classical key wrap (Phase 2)
AES-256-GCM data key wrappado simultaneamente em RSA-OAEP-2048 OU ECDH-P256 + ML-KEM-768. Unwrap precisa de ambos os privates.
POST /pqc/hybrid-classical/wrap { plaintext_key, classical_alg, classical_pub, pqc_pub }
→ { wrapped: { classical_ct, pqc_ct, iv, tag } }
POST /pqc/hybrid-classical/unwrap { wrapped, classical_priv, pqc_priv }
→ { plaintext_key }
Uso típico: envelope encryption de DEKs em storage de longa duração (backups, archives) onde threat horizon ≥ 10 anos.
Dual-sign (Phase 3)
Assina simultaneamente RSA-PSS-3072 + ML-DSA-65 (Dilithium-3). Verifier exige ambas as assinaturas válidas:
POST /pqc/dual-sign/sign { message, rsa_priv, ml_dsa_priv }
→ { rsa_sig, ml_dsa_sig }
POST /pqc/dual-sign/verify { message, rsa_sig, rsa_pub, ml_dsa_sig, ml_dsa_pub }
→ { valid: true|false, rsa_ok, ml_dsa_ok }
Use case: assinatura de release artifacts, supply chain, qualquer coisa que precise sobreviver à era pós-quântica.
KMIP PQC objects (Phase 4)
Clientes KMIP 1.4 podem Create objetos ML-KEM + ML-DSA via TTLV.
Primeira implementação open-source KMIP com PQC. Compatível com Java
KMS clients, IBM Spectrum Scale, etc.
import kmip
client.create(
object_type='SymmetricKey',
algorithm='ML-KEM-768',
cryptographic_length=24960 # bits
)
Audit Merkle checkpoint dual-signed (Phase 5)
Snapshot horário em pqc_audit_checkpoints:
- Merkle tree de audit events da última hora
- Root signed com RSA-PSS-3072 + ML-DSA-87 (highest security level)
- Permite verificação de tampering tanto hoje quanto após advento PQC
GET /pqc/audit-checkpoints/latest
# → { merkle_root, rsa_signature, ml_dsa_signature, range_start, range_end }
Auditor offline pode validar checkpoint inteiro sem necessitar do CV.
Limitações atuais
- Sem integração com
Fortressainda — você não pode marcar fortress secret como "encrypted via PQC". Roadmap v5 - Sem TLS-PQC nos endpoints HTTPS — TLS 1.3 ainda usa X25519
classical. Aguardando rfc8446bis com
X25519MLKEM768 - Audit principal continua Ed25519 — checkpoints horários (Phase 5) são PQC; events individuais ainda usam Ed25519 por overhead
Boas práticas
- Use modo híbrido sempre — quebra de algoritmo clássico OU PQC não compromete o outro
- Não substitua TLS ainda — TLS 1.3 com cipher suite híbrido é roadmap; PQC standalone em endpoints HTTPS reduz interop com clients antigos
- Avalie por caso de uso — dados de retenção curta (< 5 anos) não justificam overhead PQC
- Documente em compliance matrix — auditor pode pedir evidência de "harvest now, decrypt later" mitigation