|Yawning Angel 03f5f106d3 obfs4 padding changes, special case short writes as well.||4 years ago|
|basket2proxy||4 years ago|
|crypto||4 years ago|
|ext||4 years ago|
|framing||4 years ago|
|handshake||4 years ago|
|internal||4 years ago|
|.gitignore||4 years ago|
|CODE_OF_MERIT.md||4 years ago|
|LICENSE||4 years ago|
|README.md||4 years ago|
|client.go||4 years ago|
|common.go||4 years ago|
|padding_impl.go||4 years ago|
|padding_null.go||4 years ago|
|padding_obfs4.go||4 years ago|
|server.go||4 years ago|
|version_check.go||4 years ago|
|version_check_stub.go||4 years ago|
basket2 is the next transport in the obfs series. It derives inspiration primarily from obfs4 and predecessors, and incorporates ideas initially prototyped in the experimental basket transport.
I am waiving the remote network interaction requirements specified in Section 13 ("Remote Network Interaction; Use with the GNU General Public License") of the AGPL, per the terms of Section 7 ("Additional Terms"), for users that:
Are using the software exclusively to operate a publically accessible Bridge to provide access to the public Tor network as a Tor Pluggable Transport server. This means:
The Bridge publishes a descriptor to the Bridge Authority, and is available via BridgeDB OR is a default Bridge pre-configured and distributed with Tor Browser, and uses basket2 as a server side Pluggable Transport for said Bridge.
All other users MUST comply with the AGPL in it's entirety as a general rule, though other licensing arrangements may be possible on request. I will likely be fairly liberal here, so please contact me if the current licensing is unsuitable for your use case.
The post-quantum cryptography does not apply to active attackers in posession of a quantum computer, and only will protect pre-existing data from later decryption.
If your system has busted PMTUD, this probably won't work at all. Not my problem. Complain to your OS vendor.
This could have been based on Trevor Perin's noise protocol framework, with a decent amount of work and extensions, but certain properties and behavior I need aren't formally specified yet. This is something I will strongly consider if/when I design basket3.
Write a formal specification.
Write an AVX2 optimized Poly1305 implementation.
Someone that's not me should write assembly optimized ChaCha20 for ARM and i386. I may do both if I feel bored enough, but no promises.
Write optimized assembler versions of things for gccgo (or C if that's easier). Low priority.
Define more padding primitives.