DO NOT open public GitHub issues for security vulnerabilities.

The Quantum-Go project takes security seriously. If you discover a security vulnerability, please follow responsible disclosure practices:

1. Email the maintainers directly at: pzverkov@protonmail.com (or security contact in profile)

2. Include the following information:

   • Type of vulnerability (e.g., timing side-channel, authentication bypass, key compromise)
   • Affected version(s)
   • Steps to reproduce or proof-of-concept
   • Potential impact assessment
   • Suggested remediation (if any)
   • Your contact information for follow-up

3. Encryption (Optional but Recommended):

   • For highly sensitive disclosures, request PGP key via initial email
   • Encrypt details with provided public key

• Acknowledgment: Within 72 hours of report submission
• Initial assessment: Within 5 business days
• Status updates: Every 7 days until resolution
• Coordinated disclosure: We will work with you on disclosure timeline
• Credit: Security researchers will be credited in release notes (unless anonymity requested)

The following are explicitly not in scope for security reports:

• Denial of Service (DoS) attacks requiring >1000 requests
• Issues in third-party dependencies (report to upstream)
• Social engineering attacks
• Physical attacks requiring device access
• Theoretical attacks without practical exploitation

Note: Versions prior to v0.0.9 contain known protocol-level weaknesses in session resumption, rekey authentication, and transcript binding. Upgrade to v0.0.9+ for security-hardened protocol composition. Production use is not recommended without independent security audit.

Quantum-Go implements a Cascaded Hybrid KEM (CH-KEM) providing:

1. Post-Quantum security: ML-KEM-1024 (CRYSTALS-Kyber, NIST FIPS 203)

   • NIST Category 5 security level (~256-bit)
   • Resistant to Grover's algorithm (quantum search)
   • Based on Module Learning With Errors (MLWE) hardness

2. Classical security: X25519 (Curve25519, RFC 7748)

   • 128-bit security against classical attacks
   • Constant-time implementation (via Go stdlib)
   • Widely deployed and analyzed

3. Hybrid security guarantee:

   • System remains secure if EITHER algorithm is secure
   • Defense-in-depth against cryptanalytic breakthroughs
   • Combined secret: K = SHAKE-256(K_x || K_m || transcript || domain)

4. Authenticated encryption:

   • AES-256-GCM (FIPS 140-2 approved)
   • ChaCha20-Poly1305 (RFC 8439)
   • Nonce-misuse resistance via sequence numbering

5. Forward secrecy:

   • Ephemeral keys per session
   • Automatic rekeying (1 hour, 1GB, or 2^28 packets)
   • Old keys zeroized after use

In scope:

• Quantum adversary with Shor's algorithm (breaks RSA/ECC)
• Active network attacker (MITM, replay, tampering)
• Passive eavesdropper recording traffic for future decryption
• Compromised session keys (forward secrecy protects past sessions)

Out of scope:

• Physical attacks on runtime memory
• Side-channel attacks on non-constant-time operations
• Malicious participants (requires authentication layer)
• Post-compromise security (PCS) after long-term key compromise
• Traffic analysis / metadata leakage

1. No endpoint authentication (planned: v0.1.0):

   • The protocol provides encryption only -- no built-in peer authentication
   • Any party can initiate or accept a handshake without proving identity
   • You must implement authentication externally (certificates, PSK, static key pinning)
   • Identity binding to CH-KEM public keys is the deployer's responsibility

2. No role binding in CH-KEM transcript (planned: v0.0.10):

   • The transcript hash does not include the initiator/responder role or protocol version
   • Theoretically enables reflection attacks (initiator completes handshake with itself)
   • Mitigated in practice by the handshake state machine (separate initiator/responder flows)
   • Full fix requires adding role indicator to TranscriptHash components

3. AEAD nonce prefix is zero (planned: v0.0.10):

   • Nonce format is [0000 || counter(8B)] -- the upper 4 bytes are not session-bound
   • Two sessions with the same encryption key would produce identical nonce sequences
   • Risk is low in practice because traffic keys are derived from unique shared secrets
   • Full fix: use session ID bytes as nonce prefix

4. Replay window is 64 packets (planned: v0.0.10):

   • At high throughput (~83,000 pps at 1 Gbps), this gives <1ms tolerance for reordering
   • Packets arriving more than 64 positions out of order are silently dropped
   • Full fix: expand to 1024+ using multi-word bitmap

5. Resumption tickets not bound to server identity (planned: v0.0.10):

   • Session tickets contain only master secret and cipher suite
   • A captured ticket could theoretically be replayed against a different server
   • Risk is low: requires the attacker to know the ticket encryption key
   • Full fix: include SHA-256(server_public_key) in ticket plaintext

6. Nonce management:

   • Sequence-based nonces are safe for single-threaded or properly synchronized use
   • DO NOT use same session keys from multiple goroutines without external locking
   • Nonce exhaustion triggers automatic rekey

7. Timing side-channels:

   • ML-KEM implementation (cloudflare/circl) uses constant-time operations
   • X25519 from Go stdlib is constant-time
   • AES-GCM requires hardware AES-NI for constant-time (CPU flags checked)
   • ChaCha20-Poly1305 is software-constant-time

8. Memory safety:

   • Go runtime does not guarantee memory zeroization
   • Garbage collector may copy secrets to new locations
   • Swapping to disk may leak key material
   • Mitigation: Use HSM/TPM for long-term keys
   • v0.0.9 added runtime.KeepAlive to prevent dead store elimination of Zeroize

9. Random number generation:

   • Uses crypto/rand (Linux: getrandom syscall)
   • Ensure /dev/urandom is properly seeded on older systems
   • In virtualized environments, verify entropy availability

1. Independent security audit:

   • Engage professional cryptographic auditors
   • Review implementation against NIST FIPS 203 specification
   • Test side-channel resistance on target hardware

2. Key management:

   • Store long-term keys in Hardware Security Modules (HSM)
   • Use TPM for key derivation on edge devices
   • Implement key rotation policies (quarterly recommended)
   • Never reuse ephemeral session keys

3. Authentication layer:

   • Implement mutual authentication (X.509 certificates recommended)
   • Bind identities to CH-KEM public keys
   • Use certificate transparency for public key distribution
   • Consider TOFU (Trust On First Use) for low-security contexts

4. Monitoring & incident response:

   • Log handshake failures (potential attacks)
   • Monitor for unusual rekey rates
   • Alert on replay detection events
   • Have key revocation procedures ready

5. Compliance:

   • For FIPS 140-3: See FIPS_140_3_ROADMAP.md
   • For CNSA 2.0: ML-KEM-1024 aligns with NSA guidance
   • Ensure AES-256-GCM mode for FIPS environments

1. Deployment:

   • Enable TLS 1.3 for initial handshake transport (defense-in-depth)
   • Use pinned certificates for known peers
   • Implement connection limits per IP
   • Deploy intrusion detection systems (IDS)

2. Configuration:

   config := tunnel.TransportConfig{
       MaxMessageSize: 1024 * 1024, // 1MB max
       // Add timeouts, buffer limits
   }

   • Set conservative message size limits
   • Configure timeouts for handshake/data operations
   • Enable connection-level rate limiting

3. Testing:

   • Run fuzz tests on public-facing parsers weekly
   • Execute KAT tests before deployment
   • Perform load testing under realistic conditions
   • Test failover and rekey scenarios

4. Updates:

   • Subscribe to security advisories (GitHub Watch → Releases)
   • Monitor CVE databases for Go crypto library issues
   • Update dependencies monthly (cloudflare/circl, golang.org/x/crypto)
   • Test updates in staging before production rollout

5. Secure coding:

   // DO: Zeroize sensitive data
   defer crypto.Zeroize(secretKey)
   
   // DON'T: Log sensitive information
   // log.Printf("Shared secret: %x", secret) // NEVER DO THIS
   
   // DO: Handle errors
   if err := tunnel.InitiatorHandshake(session, conn); err != nil {
       conn.Close()
       return fmt.Errorf("handshake failed: %w", err)
   }

Dependency update policy:

• Monitor security advisories
• Update within 7 days for critical CVEs
• Test thoroughly before deployment

# Known Answer Tests (deterministic crypto verification)
go test ./pkg/crypto -v -run "TestKAT"

# Fuzz testing (security-critical parsers)
go test -fuzz=FuzzParsePublicKey -fuzztime=1h ./test/fuzz/
go test -fuzz=FuzzDecodeClientHello -fuzztime=1h ./test/fuzz/
go test -fuzz=FuzzAEADOpen -fuzztime=1h ./test/fuzz/

# Race condition detection
go test ./... -race

# Benchmark (detect performance regressions)
go test ./test/benchmark -bench=. -benchmem

Recommended for production deployments:

1. Static analysis:

   • gosec - Go security checker
   • govulncheck - Known vulnerability scanner
   • CodeQL / Semgrep

2. Fuzzing:

   • OSS-Fuzz integration (planned)
   • Custom fuzz harnesses in test/fuzz/

3. Timing analysis:

   • dudect - Constant-time verification
   • Intel PT (Processor Trace) for side-channels

When a security issue is confirmed:

1. Day 0: Acknowledgment sent to reporter
2. Day 1-5: Validation and impact assessment
3. Day 6-30: Patch development and internal testing
4. Day 31-60: Coordinated disclosure with reporter
5. Day 60: Public disclosure and release (unless extended)

Embargo Period: 90 days maximum for critical vulnerabilities, shorter for lower severity.

We acknowledge security researchers who responsibly disclose vulnerabilities:

No vulnerabilities reported yet. Be the first to help improve Quantum-Go's security!

• NIST Post-Quantum Cryptography Standardization
• NIST FIPS 203: ML-KEM Standard
• RFC 7748: Elliptic Curves for Security (X25519)
• NIST FIPS 202: SHA-3 Standard
• NSA CNSA 2.0: Quantum Transition Guidelines

Last updated: 2026-03-13 Next review: 2026-06-13 (quarterly updates)