Shadowsocks 2027 Edition: Post Quantum using ML-KEM

Inspired by Shadowsocks 2022 Edition.

Draft Proposal
Date: April 2026
Status: Draft for discussion

1. Abstract

Shadowsocks 2027 Edition introduces post-quantum security to the Shadowsocks protocol family, building on the Shadowsocks 2022 Edition. It replaces classical key exchange with ML-KEM (NIST FIPS-203 standardized Kyber), combined with a user-provided Pre-Shared Key (PSK) for hybrid quantum-resistant protection. This ensures resistance to both current threats and future quantum attacks via Shor's algorithm.

The protocol maintains AEAD semantics for TCP/UDP proxying, using AES-128-GCM or AES-256-GCM for symmetric encryption. Traffic remains indistinguishable from random bytes, evading DPI-based censorship.

New method names: 2027-mlkem-aes-128-gcm and 2027-mlkem-aes-256-gcm.

2. Key Changes from Shadowsocks 2022

1. Post-Quantum Key Encapsulation: Client generates an ML-KEM keypair, sends the public key encapsulated ciphertext to server during handshake. Server decapsulates to derive a shared secret K_ml (32 bytes for both variants).
2. PSK Integration: Retains PSK (16/32 bytes) from 2022 edition. Final traffic key K_traffic = HKDF(K_ml || PSK, "ss2027-traffic-key"), providing hybrid security (classical + post-quantum).
3. Handshake Augmentation: Adds ML-KEM overhead (~1184 bytes for ML-KEM-768) to initial payload, keeping total size under typical MTU.
4. Quantum-Resilient Symmetric Ciphers: AES-GCM with 128/256-bit keys, resistant to Grover's algorithm at reduced effective strength (128/256→64/128 bits post-quantum).
5. No Authentication Changes: Relies on PSK for server auth; optional future ML-DSA integration out-of-scope.

Method	PSK Bytes	K_ml Bytes	HKDF Salt Bytes	Security Level (Classical/Post-Quantum)
2027-mlkem-aes-128-gcm	16	32	16	128 / 128 bits
2027-mlkem-aes-256-gcm	32	32	32	256 / 128 bits

ML-KEM Parameter: Use ML-KEM-768 (Level 3 equivalent) for balance of security/performance across variants.

3. Protocol Flow

3.1 Client-to-Server Initial Packet (TCP/UDP)

[Fixed Header: 6 bytes]
- Type: 0x01 (Version 2027 handshake)
- IV: 12 bytes (random, used for subkey derivation)
- Payload Type: 0x01 (ML-KEM)

[ML-KEM Data: ~1184 bytes]
- ML-KEM-768 Ciphertext (1088 bytes)
- rho (32 bytes, randomness)

[2022 Payload Header + Encrypted Chunk]
- Follows 2022 Edition format, but with traffic key derived post-handshake

Server:

1. Validates header, extracts ML-KEM ciphertext.
2. Decapsulates using server private key → K_ml.
3. Loads user PSK, computes K_traffic = HKDF(K_ml || PSK, salt=IV, info="ss2027").
4. Decrypts payload with K_traffic + AES-GCM, responds with confirmation chunk.

3.2 Subsequent Traffic

• Identical to Shadowsocks 2022: AEAD chunks with K_traffic, Blake3 nonce derivation.
• No re-handshake; session keys persist until timeout.

3.3 UDP

• Initial datagram includes ML-KEM handshake.
• Server responds with encapsulated confirmation.

4. Cryptographic Primitives

• KEM: ML-KEM-768 (FIPS-203).
• Symmetric: AES-128/256-GCM (RFC 5288).
• HKDF: Blake3-HKDF (as in 2022 edition).
• PSK Generation: openssl rand -base64 <key_size>.
• Key Derivation:

  K_traffic = HKDF(ikm = K_ml || PSK, salt = IV, info = "ss2027-traffic-key")
  Subkeys/nonces as per 2022-blake3-aes-*-gcm
  

5. Security Considerations

• Harvest-Now-Decrypt-Later: Protected by ML-KEM (IND-CCA2 secure).
• Hybrid Design: PSK adds classical security; even if ML-KEM weakens, PSK holds.
• Side-Channels: Implement constant-time ML-KEM (use liboqs or pqclean).
• Downgrade Attacks: Version negotiation rejects pre-2027 methods.
• Performance: ML-KEM-768 encapsulation ~0.5-2ms on modern CPUs; negligible for proxies.

6. Implementer Notes

• Libraries: liboqs for ML-KEM, ring/openssl for AES-GCM.
• Key Sizes: Server stores PSK + ML-KEM private key per user (minimal overhead).
• Compatibility: Fallback to 2022 methods via config.

Key Takeaways

• Shadowsocks 2027 upgrades to ML-KEM + PSK for full post-quantum proxy security.
• Methods 2027-mlkem-aes-128-gcm/256-gcm balance speed/security.
• Minimal protocol changes; easy upgrade path from 2022.

No repository files or tests are named. Start by reviewing the Protocol Flow and Cryptographic Primitives sections, then check the 2022 Edition implementation and the listed liboqs, ring, or openssl integration points. Done means the 2027 protocol design is resolved and an agreed implementation path exists.