Main
News
Proposal
Readings
Download
License
Donate
Feedback
Guestbook
Thu Aug 7 17:08:20 2025 UTC
A new version of the source code tarball has just been published. The
changes are minor this time, but they affect the protocol, breaking
backwards compatibility; hence it is given the vers. number
0.0.20 (not 0.0.11 as it could be expected for a minor
change).
In a nutshell: I decided to obfuscate the nonce part of encrypted
datagrams. The obfuscation is not intended to be “secret” in
any way, it doesn't use any keys etc., and actually it can not be
“secret” as nonces are open information by their very nature.
However, before this change, the nonce was a 64-bit unsigned, stored in the
LSB-first byte order, sequentially incrementing by 1 dgram to
dgram, starting anywhere between 0x0100'0000'0000'0000 and
0x01ff'ffff'ffff'ffff (as the MSB is always set to 0x01 as the
communication starts, while the other seven bytes are filled randomly).
The actual nonce passed to the crypto functions is still just that; but in
the datagrams it now looks much like random data, and one needs to know how
to deobfuscate it to see the sequential numbers.
From the cryptographic point of view, this doesn't add anything to security, as the (de)obfuscation functions are open (just like all the source code here) and they do very simple things. Well, let it be :-)
Thanks to everyone who supported the project.
From Anonymous (unverified) Thu Aug 7 22:54:26 2025 UTC
Deep Packet Inspection
Was it made to protect from DPI in countries with opressive regimes?
reply
From Andrey Stolyarov
Fri Aug 8 09:20:37 2025
UTC
in reply to
this comment
Re: Deep Packet Inspection
Actually, no: the procedures of obfuscation and deobfuscation are open and simple, so, while DPI has to have them built-in, it can have them; I mean, it is obviously possible.
Such a trivial obfuscation may only work against manual inspection. I don't know how to make encrypted UDP datagrams really undetectable, and I doubt if it can be achieved at all.
As of circumventing DPI, there are VPNs that use TLS on the standart HTTPS port, so from the "inspector's" point of view they can not be distinguished from real HTTPS. However, building a network using such principle will take a lot of servers on routable IPs, ready to pass someone else's traffic through them; this only makes sense for corporations.
On the other hand, if we see our procedures within DPI one day, built-in, it will mean two things: (1) we're successful and (2) we should think about an alternate transport protocol, while keeping nodes with their keys and addressing as is. Several different transports may work simultaneously.
reply