Skip to content

ADR 0054 — Project OCTOPUS PQC-Everywhere Posture

  • Status: Accepted
  • Date: 2026-05-14
  • Deciders: André Luiz Gallon (Architect/Operator)
  • Supersedes: amplia project_oobi_satellite_pqc_hybrid_locked_2026_05_14.md para todo o OCTOPUS
  • Related: ADR 0046 (OOBI Hello encrypted payload), ADR 0048 (ZTP-Prem 12-layer), ADR 0053 (Cell-based Hyperscale)
  • Memory: project_octopus_hyperscale_admin_pqc_locked_2026_05_14.md

Context

OCTOPUS carrega tráfego TLSStress.Art através de IaaS pública. Estes hops cruzam:

  • Internet (CONNECT.Art listener público, STUN-coord UDP público)
  • Backbone cloud (entre AZs, entre regiões)
  • WAN cliente → cloud (federation tunnel mTLS)
  • Cloud → Admin Console (admin.tlsstress.art)
  • Stripe webhook → Provisioning Orchestrator

Adversário state actor com capacidade futura de computação quântica relevante (estimado 2030-2035 para algoritmos Shor-vulneráveis em chaves 2048-bit; mais tarde para curvas elípticas modernas) executa estratégia "harvest now, decrypt later": captura TLS bruto hoje, decifra quando computador quântico ficar tratável.

Tráfego TLSStress.Art pertence a verticais reguladas (telco, fintech, governo, defesa, saúde). Janela de exposição importa: contratos de 5+ anos com prova de testes em redes classificadas precisam permanecer secret indefinidamente.

NIST publicou FIPS 203 (ML-KEM, derivado de Kyber) + FIPS 204 (ML-DSA, derivado de Dilithium) em Aug 2024. Go 1.26 (Mar 2026) introduziu crypto/mlkem e crypto/mldsa stdlib. CNSA 2.0 (US NSA Commercial National Security Algorithm Suite 2.0) requer PQC hybrid em sistemas classificados a partir de 2025; full PQC mandatory até 2033. EU eIDAS 2 + UK NCSC + ANSSI seguem trajetórias paralelas.

Custo de adotar PQC hybrid em Go é mínimo (stdlib, ~1KB extra por handshake). Custo de NÃO adotar é catastrófico se decifrarem o backbone.

Decisão

OCTOPUS aplica PQC hybrid em TODOS os hops desde o Wave-1. Não há fallback "classical-only". PR reviewer DEVE rejeitar código Wave-1+ que não conforme.

Stack criptográfica

Camada Algoritmos hoje (classical) Algoritmos OCTOPUS Wave-1 (PQC hybrid)
KEX (key exchange) X25519 X25519 + ML-KEM-768 (NIST FIPS 203, Level 3)
Sigs (signatures) Ed25519 Ed25519 + ML-DSA-65 (NIST FIPS 204, Level 3)
Symmetric cipher AES-256-GCM AES-256-GCM (Grover-resistant a 128 bits post-quantum)
AEAD alt ChaCha20-Poly1305 ChaCha20-Poly1305 (mantém)
Hash SHA-256 SHA-384 mínimo (Grover-resistant); SHA-512 onde latência permite
KDF HKDF-SHA256 HKDF-SHA512
Cert chain hash SHA-256 SHA-384 (cert OCSP + CRL signatures)

Hops cobertos (sem exceção)

  1. Cliente satellite → CONNECT.Art listener (TLS 1.3-PQC mTLS)
  2. STUN-coord ↔ peer (DTLS-PQC para sinalização, payload P2P fora do escopo cloud)
  3. CONNECT.Art ↔ CONNECT.Art (cross-region replication TLS 1.3-PQC)
  4. OCTOPUS state store (DynamoDB / Spanner connection TLS 1.3-PQC)
  5. Cliente Dashboard → Admin Console — no, isso é traffic interno cliente-side, não OCTOPUS
  6. Operator → Admin Console (Auth0 + TLS 1.3-PQC + WebAuthn)
  7. Stripe webhook → Provisioning Orchestrator (Stripe não suporta PQC ainda — pinning classical-only HMAC HMAC-SHA256 com PSK em trânsito sobre TLS 1.3, plus payload re-encrypt pelo orchestrator antes de persistir)
  8. Audit chain Merkle (signatures Ed25519+ML-DSA-65)
  9. Sigstore signing (signatures Ed25519+ML-DSA-65 via sigstore PQC roadmap; até sigstore suportar nativo, dupla assinatura: classical via cosign + PQC via separate transparency log)

Triple-encryption obrigatório em hops WAN

Para federation tunnel cliente DC ↔ cloud OCTOPUS sobre Internet pública:

Layer 1 (outer):  IPsec ESP transport mode com IKEv2 PQC (X25519+ML-KEM-768)  [opt-in]
Layer 2 (middle): TLS 1.3-PQC mTLS handshake X25519+ML-KEM-768
Layer 3 (inner):  Application-layer AES-256-GCM com PSK do Hello (já existe em pkg/oobi/hello/)

Pelo menos Layer 2 + Layer 3 são MANDATORY. Layer 1 (IPsec) é opt-in para clientes classificados ou Enterprise tier "Defense-grade".

HSM-backed roots

  • Vault Enterprise com PQC support para Customer PKI (per-cell CA)
  • AWS Cloud HSM / GCP Cloud KMS HSM / Azure Dedicated HSM para root cell CA
  • YubiHSM 2 ou Nitrokey HSM para offline root (air-gap signing ceremony anual)
  • Quando Stripe e provedores SaaS adotarem PQC, atualizar via flag — interface agnóstica.

Política de PR review

PRs OCTOPUS Wave-1+ DEVEM ser rejeitados se:

  • Usem crypto/ecdh ou crypto/ed25519 sem KEM/sig PQC concomitante
  • Tenham fallback if !pqcSupported { fallbackClassical() }
  • Persistam PSK / private keys em base de dados não-HSM-backed
  • Usem SHA-256 em camada criptográfica primária (OK em fingerprinting de cert apenas, mantido para compat)

Wave-1 timeline impacto

Adotar PQC hybrid adiciona ~2 semanas Wave-1 vs classical-only:

  • PR-OCTOPUS-2 (PQC hybrid em CONNECT.Art + STUN-coord): +5 dias
  • Cert-manager Issuer PQC-ready (per-cell PKI): +3 dias
  • HSM provisioning workflow no Provisioning Orchestrator: +5 dias
  • Tests cross-impl interop (Go stdlib ↔ BoringSSL ↔ OpenSSL 3.5 OQS provider): +3 dias

Alternativas consideradas

Alternativa Por que rejeitada
PQC só em hops WAN (federation tunnel) Adversário se beneficia do elo mais fraco. Hop interno cloud-internal continua classical = vulnerável a side-channel observation de provedor IaaS comprometido.
PQC só em payload, KEX classical "Harvest now, decrypt later" continua válido — captura TLS handshake hoje, decifra chave de sessão amanhã. Inaceitável.
Adiar para "quando Stripe/AWS adotarem PQC" Adotar tarde = refactor doloroso. Go já tem stdlib. Cliente-facing cloud está pronto para PQC HOJE.
Adotar ML-KEM-1024 (Level 5) e ML-DSA-87 Level 3 (768/65) é equivalente AES-192 = suficiente até 2050+. Level 5 é overhead injustificado hoje. Atualizar quando IRSI publicar Level-5 mandate.

Consequências

Positivas

  • Patent claim #18 (PQC-everywhere posture) torna-se defensável
  • Compliance roadmap: NIST CNSA 2.0 + EU eIDAS 2 + UK NCSC já satisfeitos
  • Marketing forte: "first NGFW validator with PQC-everywhere"
  • Stripe e provedores SaaS, quando atualizarem, encaixam sem refactor
  • Vendor independence: stdlib Go, nenhum lock-in em BoringSSL ou OQS provider

Negativas

  • ~1 KB extra por TLS handshake (negligível)
  • ~5-10ms latência extra por handshake em primeira conexão (negligível para long-lived satellite tunnels)
  • HSM provisioning workflow é trabalho adicional (mas obrigatório para audit anyway)
  • Devs internos precisam aprender crypto/mlkem API (mas é stdlib Go = fácil)

Neutras

  • Dependência de Go 1.26+ — já decidido (commit 605 toolchain bump)
  • ChaCha20-Poly1305 mantido como AEAD fallback (Grover-resistant nativamente)

Patent claim potencial

Claim #18 — PQC-Everywhere Posture com Triple-Encryption em Federation Tunnel: combinação de (1) ML-KEM-768 + X25519 hybrid KEX em todos hops, (2) ML-DSA-65 + Ed25519 hybrid sigs em audit chain Merkle, (3) IPsec + TLS 1.3-PQC + application-layer AEAD triple-encryption em federation tunnel, (4) HSM-backed per-cell PKI.

Provisional draft Q3 2026 (junto com Family B/C/D), priority date locked.