wiki:doc/PluggableTransports/basket2evaluation

basket2 Transport Evaluation (Preliminary)

The basket2 transport was developed by the Tor Project in response to certain theoretical weaknesses in the obfs4 transport. It is expected to eventually supercede obfs4 protocol as the front-line Pluggable Transport used by most Tor users.

From a design standpoint, basket2 most closely resembles the obfs4 protocol, also incorporating ideas borrowed from the experimental and undeployed basket protocol.

1. Review Coverage and Reviewability Evaluation

1.1 Is the software published, and is it entirely free / open source software?

The basket2 protocol is implemented as a standalone library and companion proxy application (basket2proxy), both which are available under a FOSS license.

Additionally the non-standard cryptography that would be required to implement the basket2 protocol has FOSS implementations available.

1.2 How well documented is the design?

As the protocol is not yet finalized, the design documentation is non-existent beyond a basic README.md file and source code comments. The author plans on fully documenting the protocol on a level similar to obfs4 prior to deployment.

1.3 How much existing review has been done? Is the project active?

A request for comments was posted to the tor-dev mailing list, however no responses were received, likely owing to the early state of development.

Separate to the attempt at obtaining public review, there has been light private design review by a handful of people (some who have read the code extensively).

The project is under active development, and is more amenable to future improvements past the initial release due to the protocol itself being versioned.

1.4 What is the design's deployment history?

As the protocol and implementation are still experimental, there has been no large scale deployment at this point. The author reports annectodally of using varios revisions of the code for day to day use over a timespan of a few months in private testing.

2 Design Evaluation

2.1 How difficult or expensive will it be to block the design?

It is expected that in the default configuration, the difficulty of blocking will be comparable to obfs4, under the assumption that the obfs4 cryptography and implementation are correct (which isn't strictly true).

As the protocol supports the concept of versioned bridge lines and client driven padding/timing strategy negotiation, most weaknesses that arise can be easily corrected at a future date (unlike the obfs4 protocol which is essentially frozen at this point).

2.2 What impact on anonymity does the design have, if any?

There is no negative anonymity impact with the basket2 protocol. Depending on the padding/timing strategy negotiated between the client and bridge, substantial resistance (currently based on Tamaraw) can be obtained versus website fingerprinting attacks.

Note that the Tamaraw based padding mode comes with substantial bandwidth overhead and a reduction in protocol obfuscation and thus is disabled by default. The default padding/timing strategy instead is based off the obfs4 design.

2.3 What is the design's overhead in terms of computational costs and bandwidth?

The amount of additional overhead depends on a few factors. With the default padding mode, both overheads are expected to be roughly comparable to that of obfs4, with a slightly more CPU intensive handshake (approx 2 to 4x).

The Tamaraw based anti-website fingerprinting mode of operation involves sending quite a bit of additional padding, with an overhead of approx 100%, however this mode will not be enabled by default.

The author plans on adding a faster handshake variant that omits the Ring-LWE based handshake (purely ECC based), which will bring the handshake performance to approximately obfs4 speeds, however this is not expected to be the main performance bottleneck.

The bulk transmission CPU overhead is significantly reduced over that of obfs4 on modern hardware where AVX2 is available. It is expected that relatively modest server hardware can comfortably sustain bulk transfers of over 1 Gbps.

2.4 How resilient is the design to active probing?

The basket2 protocol requires that the client proves to the server that it knows a public key belonging to the server before the server will respond with any traffic, and thus is immune to active probing attacks.

3 Implementation Evaluation

3.1 Does the design use the Tor Project's Pluggable Transport Application Programming Interface already?

Yes, basket2proxy uses the PT API.

3.2 Is the implementation cross-platform? How about mobile support?

The Go implementation is currently being developed on x86_64 Linux, with light testing on x86 Linux having been done. The code is inherently portable (the assembly optimizations are optional), and should run without problems on any platform the Go compiler can target.

3.3 What is the implementation's build process like, how easy is it to deploy, and what is deployment scaling like?

basket2proxy is capable of being built deterministically and is planned to be integrated into the Tor Browser's build process. Deployment scaling is similar to any other bridge based Pluggable Transport.

3.4 How is the implementation's code from a security and maintainability perspective?

The basket2 package is written in Go which is a memory-safe language. Test coverage while, not complete encompasses most of the non-trivial components.

Some of the low level cryptography routines incorporated as a dependency is hand written in x86_64 assembly language which is neither memory safe nor easy to maintain, however the critical components has good test coverage.

3.5 How well-instrumented is the implementation in terms of collecting usage / performance / etc metrics?

basket2proxy fully supports the Extended ORPort mechanism and thus provides metrics information.

Last modified 15 months ago Last modified on Jul 8, 2016, 7:20:51 PM