Tor 0.3.0.1-alpha: A new alpha series begins
Posted December 19th, 2016 by nickm
https://blog.torproject.org/blog/tor-0301-alpha-new-alpha-series-begins
Now that Tor 0.2.9.8 is stable, it's time to release a new alpha series for testing and bug-hunting!
Tor 0.3.0.1-alpha is the first alpha release in the 0.3.0 development series. It strengthens Tor's link and circuit handshakes by identifying relays by their Ed25519 keys, improves the algorithm that clients use to choose and maintain their list of guards, and includes additional backend support for the next-generation hidden service design. It also contains numerous other small features and improvements to security, correctness, and performance.
You can download the source from the usual place on the website. Packages should be available over the next weeks, including an alpha TorBrowser release some time in January.
Please note: This is an alpha release. Please expect more bugs than usual. If you want a stable experience, please stick to the stable releases.
Below are the changes since 0.2.9.8.
Changes in version 0.3.0.1-alpha - 2016-12-19
Major features (guard selection algorithm):
Tor's guard selection algorithm has been redesigned from the ground up, to better support unreliable networks and restrictive sets of entry nodes, and to better resist guard-capture attacks by hostile local networks. Implements proposal 271; closes ticket 19877.
Major features (next-generation hidden services):
Relays can now handle v3 ESTABLISH_INTRO cells as specified by prop224 aka "Next Generation Hidden Services". Service and clients don't use this functionality yet. Closes ticket 19043. Based on initial code by Alec Heifetz.
Relays now support the HSDir version 3 protocol, so that they can can store and serve v3 descriptors. This is part of the next- generation onion service work detailled in proposal 224. Closes ticket 17238.
Major features (protocol, ed25519 identity keys):
Relays now use Ed25519 to prove their Ed25519 identities and to one another, and to clients. This algorithm is faster and more secure than the RSA-based handshake we've been doing until now. Implements the second big part of proposal 220; Closes ticket 15055.
Clients now support including Ed25519 identity keys in the EXTEND2 cells they generate. By default, this is controlled by a consensus parameter, currently disabled. You can turn this feature on for testing by setting ExtendByEd25519ID in your configuration. This might make your traffic appear different than the traffic generated by other users, however. Implements part of ticket 15056; part of proposal 220.
Relays now understand requests to extend to other relays by their Ed25519 identity keys. When an Ed25519 identity key is included in an EXTEND2 cell, the relay will only extend the circuit if the other relay can prove ownership of that identity. Implements part of ticket 15056; part of proposal 220.