arsenal intel tree about store contact
~/home / arsenal store / quantum_pentest
// 004 · POST-QUANTUM ASSESSMENT Q-DAY · ~6 YEARS

Quantum
Pentest.

Your secrets today are tomorrow's plaintext. We inventory your cryptography, model your harvest-now-decrypt-later exposure, and engineer your migration to post-quantum primitives before the clock runs out.

audit cryptography view methodology
qsim@stealthbyte · audit-0x7F3A
#01
what it is

The cryptographic reckoning is coming.

// the discipline Cryptographic inventory + migration engineering

We map every place cryptography lives in your stack — TLS endpoints, JWTs, code signing, VPN tunnels, database encryption, certificate chains, hardware tokens, code-embedded keys. For each, we identify what's quantum-vulnerable (RSA, ECDSA, ECDH, DH), what's quantum-resistant (AES-256, SHA-2/3 with adequate parameters), and what your migration path looks like.

The result is a Cryptographic Bill of Materials (CBOM) and a phased migration plan to NIST-standardized post-quantum primitives.

// why you need it now Harvest now, decrypt later

State adversaries are already harvesting encrypted traffic and storing it for future decryption. Anything your organization transmits today with RSA or elliptic-curve crypto is potentially readable to a sufficiently capable quantum adversary in 5–10 years — and the secrets you keep (M&A plans, source code, customer data, IP) have shelf lives that exceed that window.

NIST PQC standards (ML-KEM, ML-DSA, SLH-DSA) shipped in 2024. Federal mandates require migration by 2030–2035. Regulated industries should be assessing now.

// 001

Cryptographic Inventory (CBOM)

Full enumeration of every cryptographic primitive in use across your infrastructure, applications, and supply chain. Algorithm, key size, lifetime, exposure.

// 002

Harvest-Now Threat Modeling

For each cryptographic asset, model the harvest-now-decrypt-later (HNDL) risk based on data sensitivity, transmission volume, and likely adversary capability.

// 003

PQC Migration Engineering

Phased migration to NIST-standardized algorithms (ML-KEM, ML-DSA, SLH-DSA). Hybrid implementations for backward compatibility. Performance validation.

// 004

Compliance Mapping

NSA CNSA 2.0, NIST SP 800-208, BSI TR-02102, ETSI TS 119, CNSSI 1300. We map your migration to the standards that govern your industry.

#02
how it works

Four phases. One migration.

01

Crypto Discovery

Automated + manual scanning across infrastructure, applications, certificates, code repositories, vendor integrations, and hardware tokens. Builds the CBOM.

Duration 2–4 weeks
02

Risk Modeling

For each crypto asset, model HNDL risk, data sensitivity decay, regulatory horizon, and replacement complexity. Rank by impact × urgency.

Output Risk register
03

Migration Design

Phased PQC migration plan. Hybrid (classical + PQC) implementations for backward compatibility. Performance benchmarks. Vendor coordination plan.

Output Roadmap
04

Pilot & Validate

Reference implementation on selected critical paths. Performance & interoperability validation. Detection content for crypto-protocol downgrade attacks.

Output Working pilot
#03
inside the audit

Cryptography, measured.

// shor_simulation.viz RSA-2048 · attack model
CLASSICAL · TLS 1.3 QUANTUM ATTACK RECOVERED KEY RSA-2048 n = p × q ciphertext harvested 2025 archive stored · adversary SHOR · O(log³ N) p, q recovered 2030+ · plaintext
// crypto_audit.telemetry live · client #247
Assets Scanned
2,847
+ 138 today
Q-Vulnerable
62%
RSA/ECDSA exposure
HNDL Risk
CRIT
14 critical paths
Migration Cost
~$2.4M
3-yr phased plan
Discovery progress88%
Quantum-vulnerable62%
Hybrid-ready18%
// hybrid_kex.py migration pattern · classical + PQC 
# hybrid key exchange — X25519 + ML-KEM-768
from stealthbyte.pqc import ML_KEM_768, X25519

def handshake(peer):
    # classical leg — for current peers
    x25519_pk = X25519.keygen()
    x25519_ss = X25519.derive(peer.x25519_pk)

    # PQC leg — quantum-resistant
    mlkem_pk, mlkem_sk = ML_KEM_768.keygen()
    ct, mlkem_ss = ML_KEM_768.encap(peer.mlkem_pk)

    # concatenate both into master secret
    return hkdf(x25519_ss + mlkem_ss,
                info="tls13 hybrid v1",
                length=48)
// crypto_inventory.live 2,847 assets · 62% vulnerable
RSA-2048
TLS · prod load balancers · 412 endpoints
Q-VULN
ECDSA P-256
Code signing · CI/CD pipeline · 28 keys
Q-VULN
ECDH P-384
VPN concentrators · site-to-site · 14 tunnels
Q-VULN
AES-128-GCM
Database encryption · 47 instances
UPGRADE
AES-256-GCM
S3 · KMS-wrapped · 1,247 buckets
SAFE
SHA-384
Container image hashing · all registries
SAFE
DH-1024
Legacy IPSec · 3 partner integrations
CRIT
#04
what you get

Three artifacts. One migration plan.

// 01 · executive 15–25 pages

The Migration Brief

Plain-language summary of cryptographic exposure, HNDL risk to the business, regulatory timelines, and phased investment recommendations.

  • HNDL risk register (top 50)
  • Regulatory compliance map
  • 3-yr migration cost model
  • Board-ready risk narrative
// 02 · technical CBOM + roadmap

The CBOM & Roadmap

Every cryptographic asset enumerated, scored, and assigned a migration path. CycloneDX-CBOM format; machine-readable.

  • CycloneDX 1.6 CBOM
  • Per-asset migration playbooks
  • Vendor coordination tracker
  • Performance benchmarks
// 03 · pilot working code

The Pilot Implementation

Working reference implementation on one critical path. Hybrid classical+PQC handshake. Interoperability tested. Detection content for downgrade attacks.

  • Reference hybrid TLS deployment
  • Interop test results vs. partners
  • Performance regression analysis
  • Downgrade detection rules
#05
engagement models

Three ways to migrate.

// scoped

Crypto inventory

Targeted CBOM build + HNDL risk modeling for one business unit or product line. Delivered in 6 weeks. The minimum viable starting point.

  • 6-week assessment
  • Single business unit / product
  • Full CBOM in CycloneDX 1.6
  • HNDL risk register
  • Executive + technical brief
brief operators →
// flagship

Enterprise roadmap

Full enterprise cryptographic assessment + 3-year migration roadmap + working pilot on selected critical path. The standard for regulated industries.

  • 12–16 week engagement
  • Enterprise-wide scope
  • 3-year phased roadmap
  • Working pilot implementation
  • Vendor coordination support
deploy roadmap →
// continuous

Migration partnership

Embedded crypto-migration team for multi-year programs. Quarterly milestones, vendor coordination, regulator briefing support, continuous CBOM maintenance.

  • Embedded migration team
  • Quarterly milestone delivery
  • Continuous CBOM updates
  • Regulator-facing support
  • 3-year program commitment
discuss partnership →
#06
common questions

Before you migrate.

01 When does the quantum threat actually become real? +
Consensus estimates put a cryptographically-relevant quantum computer (CRQC) at 5–15 years away. But the harvest-now-decrypt-later threat is real today: data encrypted with RSA/ECDH that you transmit now could be decrypted in 2035+ if intercepted and stored. For any data with a confidentiality lifetime longer than the CRQC horizon, the threat is already operative. Most enterprises have 5–10 years' worth of in-flight migration work — starting in 2026 is appropriate.
02 Which PQC algorithms do you recommend? +
We default to the NIST-standardized set: ML-KEM (FIPS 203, formerly Kyber) for key encapsulation, ML-DSA (FIPS 204, formerly Dilithium) for digital signatures, and SLH-DSA (FIPS 205, formerly SPHINCS+) for stateless hash-based signatures where signature size matters less than algorithmic conservatism. For hybrid deployments we typically pair X25519+ML-KEM-768 in TLS 1.3 (per IETF draft-ietf-tls-hybrid-design).
03 Will PQC migration break our existing infrastructure? +
Done correctly, no. Hybrid implementations (classical + PQC concatenated) maintain backward compatibility with non-PQC peers while protecting against quantum adversaries. Performance overhead is modest for most use cases — ML-KEM-768 adds ~2KB per handshake and ~1ms CPU. The hard work is dependency tracking (your TLS terminator, your CDN, your HSMs, your customer integrations) rather than the cryptography itself.
04 What about symmetric crypto and hashing? Are those safe? +
AES-256 and SHA-2/3 with adequate output length (≥384 bits) are considered quantum-resistant against currently-known attacks (Grover's algorithm provides only quadratic speedup, so key length doubling is sufficient). AES-128 is borderline — we recommend upgrading to AES-256 where feasible. Legacy ciphers (3DES, RC4) and hashes (MD5, SHA-1) are already broken classically and must be retired immediately.
05 Are there regulatory mandates we need to meet? +
Yes. US federal: NSA CNSA 2.0 requires PQC migration for NSS by 2035 (signed-code by 2030). EU: ENISA PQC migration guidance applies under NIS2. Financial services: FFIEC, FCA, and BaFin have signaled crypto-agility requirements. Healthcare and critical infra: NIST SP 800-208 / OMB M-23-02 require inventories and migration plans. We map your assessment to the specific regimes governing your industry.
06 Can you assess hardware security modules and embedded systems? +
Yes — HSM and embedded inventory is a major component of every flagship engagement. We work with vendor roadmaps (Thales, Entrust, Utimaco, AWS CloudHSM) for migration support, and for legacy embedded systems we model the cost of in-place upgrade vs. replacement vs. compensating controls. Hardware migration is typically the long-pole item — 18–36 months of vendor-coordinated work — and starting the inventory early is essential.
begin migration · encrypted channel

Your most valuable secrets
are already being harvested.

Crypto-discovery sessions begin under NDA. Initial CBOM scan delivers within 14 days.

./begin_cbom.sh