shadowsocks-rust has supported the 2022 edition for years while libev was
stuck on the 2017 AEAD construction, the largest functional gap between
the two implementations. This adds the three SIP022 methods:
2022-blake3-aes-128-gcm
2022-blake3-aes-256-gcm
2022-blake3-chacha20-poly1305
TCP uses BLAKE3 derive_key for session subkeys, standalone header chunks
carrying a type byte and timestamp, request padding, and a response header
echoing the request salt. Replay protection uses an exact-match salt pool
with 60s retention rather than the bloom filter, which SIP022 forbids
because false positives are unacceptable there.
UDP is session-based: an AES-ECB separate header for the AES methods and a
merged XChaCha20-Poly1305 construction for ChaCha, with a per-session
sliding window replay filter. Servers must route by client session ID,
which is only known after decryption, so the crypto layer owns the
server-side session table and hands the session back to udprelay for the
reply path.
The 2022 code lives in aead2022.c and aead2022_udp.c so aead.c keeps its
current size, with aead_internal.h carrying what they share. BLAKE3 is
vendored (portable backend only) as its own build target.
Keys are base64 pre-shared keys of exactly the cipher's key size; per
SIP022 a password is never stretched into a key.
Verified interoperable in both directions against shadowsocks-rust 1.24.0
for all three ciphers over TCP and UDP, including an 8MB transfer checked
by digest, plus unit tests for header framing, partial delivery, tamper
detection, and UDP replay rejection.
shadowsocks-libev doesn't support connecting through an upstream HTTP
proxy, so if the test environment requires that then there's nothing we can
do. (In future it might be possible to set up a local server to avoid this
problem.)
Max Lv
Colin Watson
Roger Shimizu