[NEW VERSION] New version here -> https://github.com/SlimRG/shadowsocks-reborn

[SlimRG]

[NEW VERSION] New version here -> https://github.com/SlimRG/shadowsocks-reborn

[SlimRG]

What changes were made to the encrypt function in this new version?

Thanks for asking. The important point is that I did not introduce a custom Shadowsocks encryption algorithm or change the Shadowsocks AEAD wire format. The main work was a modernization and cleanup of the encryption implementation itself.

The original shadowsocks-windows implementation used several native crypto backends depending on the selected cipher: mbedTLS, libsodium and OpenSSL, accessed from C# through native interop.

In Shadowsocks Reborn, the supported AEAD ciphers are implemented directly on top of the cryptographic primitives provided by .NET 10 / System.Security.Cryptography.

Currently the main encrypted methods are:

• aes-128-gcm
• aes-192-gcm
• aes-256-gcm
• chacha20-ietf-poly1305

The default remains:

chacha20-ietf-poly1305

plain / none also exist for special cases, but obviously they do not provide encryption and are not intended as secure defaults.

What actually changed

1. Native crypto backends were removed

The old client had separate implementations such as:

• AEADMbedTLSEncryptor
• AEADSodiumEncryptor
• AEADOpenSSLEncryptor

The new implementation uses a single managed backend:

AEADBclEncryptor

Internally it uses:

• .NET AesGcm
• .NET ChaCha20Poly1305

So there is no longer a need to ship or dynamically load mbedTLS/libsodium/OpenSSL just to perform normal Shadowsocks AEAD encryption.

This is especially important for the new architecture because the application is intended to be distributed as a single x64 executable, without a collection of native crypto DLLs next to it.

2. The Shadowsocks AEAD protocol itself remains compatible

The change of crypto backend does not mean that I changed the protocol.

The implementation still follows the standard Shadowsocks AEAD construction:

• per-connection random salt;
• master key derived from the configured password;
• session/subkey derived with HKDF;
• HKDF-SHA1 with "ss-subkey" as the info value;
• authenticated AEAD tags;
• standard Shadowsocks TCP chunk framing;
• standard UDP AEAD framing;
• nonce incrementing according to the Shadowsocks AEAD protocol.

So, for example, a server configured with:

chacha20-ietf-poly1305

does not need any modification because the Windows client now uses the .NET ChaCha20-Poly1305 implementation internally.

The resulting traffic is still ordinary Shadowsocks traffic. This is an implementation change, not a new incompatible protocol.

3. A concurrency problem in key handling was removed

This is one of the more important internal changes.

The old AEAD base implementation used a static master-key field:

static byte[] _Masterkey

That means the key material was shared at the class level rather than being owned exclusively by an individual encryptor instance.

That design is undesirable when multiple connections — especially connections to different servers/passwords — exist concurrently.

The new implementation keeps the master key per encryptor instance.

In simplified terms, instead of shared state:

static master key

the model is now:

connection/encryptor instance -> its own master key -> its own encryption/decryption subkeys

Encryption and decryption also maintain independent subkeys and cipher instances.

This makes ownership of cryptographic state substantially clearer and avoids one connection being able to overwrite key material belonging to another encryptor instance.

4. Key derivation no longer depends on native libraries

The old implementation used mbedTLS for operations such as MD5/HKDF.

The new code uses .NET cryptography directly.

The compatibility-oriented password derivation required by the existing Shadowsocks implementation is retained, while the session key is derived using the .NET HKDF implementation.

Conceptually:

password -> master key

then:

salt + master key + "ss-subkey" -> per-session AEAD key

This is still compatible with the existing protocol.

5. AEAD context lifetime is managed explicitly

Instead of unmanaged native cipher contexts allocated through pointers, the new implementation owns normal .NET cryptographic objects:

• encryption AesGcm
• decryption AesGcm
• encryption ChaCha20Poly1305
• decryption ChaCha20Poly1305

They are disposed when the encryptor is disposed.

Sensitive byte arrays containing:

• the master key;
• encryption subkey;
• decryption subkey

are explicitly cleared with CryptographicOperations.ZeroMemory() during disposal.

So the change is not just “replace one encryption call with another”; the lifetime of the cryptographic state was redesigned as well.

6. Encryption/decryption now performs stricter validation

The new implementation checks things such as:

• whether the destination ciphertext buffer is large enough;
• whether a received AEAD ciphertext is at least large enough to contain its authentication tag;
• whether the encryption/decryption context was initialized;
• whether ChaCha20-Poly1305 is supported by the current Windows/.NET runtime.

Authentication/decryption failures are converted into a proper crypto error rather than allowing invalid plaintext to continue through the proxy pipeline.

7. XChaCha20-Poly1305 is intentionally not registered

The old libsodium implementation also exposed:

xchacha20-ietf-poly1305

The current managed implementation intentionally does not register it.

The goal is to keep the supported set around well-defined AEAD algorithms that have direct, maintained implementations in the .NET cryptographic stack rather than bringing back a native dependency only for an additional cipher.

If there is a strong compatibility reason to support XChaCha again, it can be discussed separately, but I would prefer not to reintroduce native crypto binaries just for that.

8. Crypto regression tests were added

The new implementation has deterministic test vectors for:

• AES-128-GCM
• AES-192-GCM
• AES-256-GCM
• ChaCha20-IETF-Poly1305

The tests verify both the produced ciphertext/tag and successful decryption.

There is also an explicit test verifying that XChaCha is not accidentally registered again.

Why make this change?

The larger goal of Shadowsocks Reborn is not simply to reskin the old Windows client.

The project is being moved to a modern Windows architecture:

• .NET 10;
• WinUI 3;
• Windows 10/11;
• x64 only;
• single-file distribution;
• removal of old native/legacy dependencies where they are no longer necessary.

Crypto was one of the areas where the old client still depended heavily on native libraries and P/Invoke.

Moving the normal Shadowsocks AEAD implementation to the maintained .NET cryptographic stack substantially simplifies deployment and maintenance while preserving compatibility with existing Shadowsocks servers.

So, in short:

old implementation:

Shadowsocks protocol -> C# wrappers -> mbedTLS/libsodium/OpenSSL -> native crypto

new implementation:

Shadowsocks protocol -> .NET 10 System.Security.Cryptography -> OS/runtime crypto implementation

The protocol and password configured on the server do not change.

There is no proprietary encryption added, and I definitely do not want to create a custom cryptographic protocol.

If you're asking because you maintain a Shadowsocks server/client implementation and need byte-for-byte compatibility details, I can also document the exact salt/key/HKDF/nonce/chunk flow used by the new implementation and provide the test vectors.

[darlcydney26]

If the modernization involved cleanup of the encrypt and decrypt routines, I am curious if you migrated the AE

[cherryrodney26]

Following up on the AEAD implementation mentioned, have you verified if the transition to cryptography.hazmat maintains the expected behavior for AEAD_CHACHA20_POLY1305 when handling large data streams? Specifically, I am interested to know if you are using CipherContext.update_into to mitigate memory pressure, or if the new version still allocates new buffers for every encrypt call. Please clarify if the nonce handling logic now enforces the 96-bit limit check to prevent accidental reuse during multi-packet sequences.