Re: WireGuard obfuscation & active probing: staying virtuous under pressure

Ian Chen <[email protected]> Sun, 26 Apr 2026 12:50:46 +0800
Newsgroups com.zx2c4.lists.wireguard
Message-ID <LV5PR01MB9941488AF3542FDC61728406C8D2292@LV5PR01MB994148.prod.exchangelabs.com>
On Wed, 2026-04-22 at 19:32 +0800, Ian Chen wrote:
> > WireGuard over Shadowsocks-2022
> > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D
> >=20
> > TL;DR: Too much crypto + deployment challenges.
> >=20
> > Shadowsocks is a good solution against censor, but it strips 40
> > more
> > bytes from MTU and AEADs data twice: XChaCha20-Poly1305 of
> > Shadowsocks +
> > ChaCha20-Poly1305 of WireGuard burning twice as much carbon
> > credits.
> > Performance matters: e.g. Mullvad introduces LWO claiming
> > performance
> > improvement over Shadowsocks.
>=20
> I developed swgp-go around the same time I wrote the spec for
> Shadowsocks 2022. At the time, I intentionally left replay protection
> out of swgp-go, because I thought WireGuard wouldn't need it.
>=20
> Thanks to your work, I now understand that this assumption was wrong!
> So I added it into swgp-go:
> https://github.com/database64128/swgp-go/commit/207a055ab0a1058579f299fc1=
021cc64c95b21db
>=20
> The new "zero-overhead-2026" and "paranoid-2026" modes provide replay
> protection for handshake packets. Replayed packets are dropped by
> checking the nonce and an encrypted unix epoch timestamp, similar to
> how Shadowsocks 2022's TCP construction does it.
>=20
> This won't address the "DoSer" scenario, but should provide enough
> protection against censors without knowledge of the OBFSK.

I sent the previous email a few days ago, and it never showed up on the
mailing list archive, probably due to all that PGP signing stuff I
didn't turn off. Let's see if this one works.