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.

[database64128]

AI slop

[Mygod]

Perfect proposal for upgrading human slop

AI slop

@database64128 What's wrong with my idea? Yes I used AI to polish my writing though.

Perfect proposal for upgrading human slop

Current Shadowsocks-2022 and older variations are not Quantum resistant IIUC, which is why I suggested Kyber X25519 method, which is already supported

[therealtunge]

actually slop wtf