Tor is released: a new series is stable!

Tor is the first stable release of the Tor 0.3.0 series.
With the 0.3.0 series, clients and relays now use Ed25519 keys to authenticate their link connections to relays, rather than the old RSA1024 keys that they used before. (Circuit crypto has been Curve25519-authenticated since We have also replaced the guard selection and replacement algorithm to behave more robustly in the presence of unreliable networks, and to resist guard- capture attacks.
This series also includes numerous other small features and bugfixes, along with more groundwork for the upcoming hidden-services revamp.
Per our stable release policy, we plan to support the Tor 0.3.0 release series for at least the next nine months, or for three months after the first stable release of the 0.3.1 series: whichever is longer. If you need a release with long-term support, we recommend that you stay with the 0.2.9 series.
If you build Tor from source, you can find it at the usual place on the website. Packages should be ready over the next weeks, with a Tor Browser release in late May or early June.
Below are the changes since For a list of only the changes since, see the ChangeLog file.

Changes in version - 2017-04-26

  • Major features (directory authority, security):
    • The default for AuthDirPinKeys is now 1: directory authorities will reject relays where the RSA identity key matches a previously seen value, but the Ed25519 key has changed. Closes ticket 18319.
  • 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):
    • 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.
    • 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.
  • Major features (security):
    • Change the algorithm used to decide DNS TTLs on client and server side, to better resist DNS-based correlation attacks like the DefecTor attack of Greschbach, Pulls, Roberts, Winter, and Feamster. Now relays only return one of two possible DNS TTL values, and clients are willing to believe DNS TTL values up to 3 hours long. Closes ticket 19769.
  • Major bugfixes (client, onion service, also in
    • Fix a client-side onion service reachability bug, where multiple socks requests to an onion service (or a single slow request) could cause us to mistakenly mark some of the service's introduction points as failed, and we cache that failure so eventually we run out and can't reach the service. Also resolves a mysterious "Remote server sent bogus reason code 65021" log warning. The bug was introduced in ticket 17218, where we tried to remember the circuit end reason as a uint16_t, which mangled negative values. Partially fixes bug 21056 and fixes bug 20307; bugfix on
  • Major bugfixes (crash, directory connections):
    • Fix a rare crash when sending a begin cell on a circuit whose linked directory connection had already been closed. Fixes bug 21576; bugfix on Reported by Alec Muffett.
  • Major bugfixes (directory authority):
    • During voting, when marking a relay as a probable sybil, do not clear its BadExit flag: sybils can still be bad in other ways too. (We still clear the other flags.) Fixes bug 21108; bugfix on
  • Major bugfixes (DNS):
    • Fix a bug that prevented exit nodes from caching DNS records for more than 60 seconds. Fixes bug 19025; bugfix on
  • Major bugfixes (IPv6 Exits):
    • Stop rejecting all IPv6 traffic on Exits whose exit policy rejects any IPv6 addresses. Instead, only reject a port over IPv6 if the exit policy rejects that port on more than an IPv6 /16 of addresses. This bug was made worse by 17027 in, which rejected a relay's own IPv6 address by default. Fixes bug 21357; bugfix on commit 004f3f4e53 in
  • Major bugfixes (parsing):
    • Fix an integer underflow bug when comparing malformed Tor versions. This bug could crash Tor when built with --enable-expensive-hardening, or on Tor through Tor, which were built with -ftrapv by default. In other cases it was harmless. Part of TROVE-2017-001. Fixes bug 21278; bugfix on 0.0.8pre1. Found by OSS-Fuzz.
    • When parsing a malformed content-length field from an HTTP message, do not read off the end of the buffer. This bug was a potential remote denial-of-service attack against Tor clients and relays. A workaround was released in October 2016, to prevent this bug from crashing Tor. This is a fix for the underlying issue, which should no longer matter (if you applied the earlier patch). Fixes bug 20894; bugfix on Bug found by fuzzing using AFL (
  • Major bugfixes (scheduler):
    • Actually compare circuit policies in ewma_cmp_cmux(). This bug caused the channel scheduler to behave more or less randomly, rather than preferring channels with higher-priority circuits. Fixes bug 20459; bugfix on
  • Major bugfixes (security, also in
    • Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes--and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on
  • Minor feature (client):
    • Enable IPv6 traffic on the SocksPort by default. To disable this, a user will have to specify "NoIPv6Traffic". Closes ticket 21269.
  • Minor feature (fallback scripts):
    • Add a check_existing mode to, which checks if fallbacks in the hard-coded list are working. Closes ticket 20174. Patch by haxxpop.
  • Minor feature (protocol versioning):
    • Add new protocol version for proposal 224. HSIntro now advertises version "3-4" and HSDir version "1-2". Fixes ticket 20656.
  • Minor features (ciphersuite selection):
    • Allow relays to accept a wider range of ciphersuites, including chacha20-poly1305 and AES-CCM. Closes the other part of 15426.
    • Clients now advertise a list of ciphersuites closer to the ones preferred by Firefox. Closes part of ticket 15426.
  • Minor features (controller):
    • Add "GETINFO sr/current" and "GETINFO sr/previous" keys, to expose shared-random values to the controller. Closes ticket 19925.
    • When HSFETCH arguments cannot be parsed, say "Invalid argument" rather than "unrecognized." Closes ticket 20389; patch from Ivan Markin.
  • Minor features (controller, configuration):
    • Each of the *Port options, such as SocksPort, ORPort, ControlPort, and so on, now comes with a __*Port variant that will not be saved to the torrc file by the controller's SAVECONF command. This change allows TorBrowser to set up a single-use domain socket for each time it launches Tor. Closes ticket 20956.
    • The GETCONF command can now query options that may only be meaningful in context-sensitive lists. This allows the controller to query the mixed SocksPort/__SocksPort style options introduced in feature 20956. Implements ticket 21300.
  • Minor features (diagnostic, directory client):
    • Warn when we find an unexpected inconsistency in directory download status objects. Prevents some negative consequences of bug 20593.
  • Minor features (directory authorities):
    • Directory authorities now reject descriptors that claim to be malformed versions of Tor. Helps prevent exploitation of bug 21278.
    • Reject version numbers with components that exceed INT32_MAX. Otherwise 32-bit and 64-bit platforms would behave inconsistently. Fixes bug 21450; bugfix on 0.0.8pre1.
  • Minor features (directory authority):
    • Add a new authority-only AuthDirTestEd25519LinkKeys option (on by default) to control whether authorities should try to probe relays by their Ed25519 link keys. This option will go away in a few releases--unless we encounter major trouble in our ed25519 link protocol rollout, in which case it will serve as a safety option.
  • Minor features (directory cache):
    • Relays and bridges will now refuse to serve the consensus they have if they know it is too old for a client to use. Closes ticket 20511.
  • Minor features (ed25519 link handshake):
    • Advertise support for the ed25519 link handshake using the subprotocol-versions mechanism, so that clients can tell which relays can identity themselves by Ed25519 ID. Closes ticket 20552.
  • Minor features (entry guards):
    • Add UseEntryGuards to TEST_OPTIONS_DEFAULT_VALUES in order to not break regression tests.
    • Require UseEntryGuards when UseBridges is set, in order to make sure bridges aren't bypassed. Resolves ticket 20502.
  • Minor features (fallback directories):
    • Allow 3 fallback relays per operator, which is safe now that we are choosing 200 fallback relays. Closes ticket 20912.
    • Annotate with the bandwidth and consensus weight for each candidate fallback. Closes ticket 20878.
    • Display the relay fingerprint when downloading consensuses from fallbacks. Closes ticket 20908.
    • Exclude relays affected by bug 20499 from the fallback list. Exclude relays from the fallback list if they are running versions known to be affected by bug 20499, or if in our tests they deliver a stale consensus (i.e. one that expired more than 24 hours ago). Closes ticket 20539.
    • Make it easier to change the output sort order of fallbacks. Closes ticket 20822.
    • Reduce the minimum fallback bandwidth to 1 MByte/s. Part of ticket 18828.
    • Require fallback directories to have the same address and port for 7 days (now that we have enough relays with this stability). Relays whose OnionOO stability timer is reset on restart by bug 18050 should upgrade to Tor or later, which has a fix for this issue. Closes ticket 20880; maintains short-term fix in
    • Require fallbacks to have flags for 90% of the time (weighted decaying average), rather than 95%. This allows at least 73% of clients to bootstrap in the first 5 seconds without contacting an authority. Part of ticket 18828.
    • Select 200 fallback directories for each release. Closes ticket 20881.
  • Minor features (fingerprinting resistence, authentication):
    • Extend the length of RSA keys used for TLS link authentication to 2048 bits. (These weren't used for forward secrecy; for forward secrecy, we used P256.) Closes ticket 13752.
  • Minor features (geoip):
    • Update geoip and geoip6 to the April 4 2017 Maxmind GeoLite2 Country database.
  • Minor features (geoip, also in
    • Update geoip and geoip6 to the January 4 2017 Maxmind GeoLite2 Country database.
  • Minor features (infrastructure):
    • Implement smartlist_add_strdup() function. Replaces the use of smartlist_add(sl, tor_strdup(str)). Closes ticket 20048.
  • Minor features (linting):
    • Enhance the changes file linter to warn on Tor versions that are prefixed with "tor-". Closes ticket 21096.
  • Minor features (logging):
    • In several places, describe unset ed25519 keys as "<unset>", rather than the scary "AAAAAAAA...AAA". Closes ticket 21037.
  • Minor features (portability, compilation):
    • Autoconf now checks to determine if OpenSSL structures are opaque, instead of explicitly checking for OpenSSL version numbers. Part of ticket 21359.
    • Support building with recent LibreSSL code that uses opaque structures. Closes ticket 21359.
  • Minor features (relay):
    • We now allow separation of exit and relay traffic to different source IP addresses, using the OutboundBindAddressExit and OutboundBindAddressOR options respectively. Closes ticket 17975. Written by Michael Sonntag.
  • Minor features (reliability, crash):
    • Try better to detect problems in buffers where they might grow (or think they have grown) over 2 GB in size. Diagnostic for bug 21369.
  • Minor features (testing):
    • During 'make test-network-all', if tor logs any warnings, ask chutney to output them. Requires a recent version of chutney with the 21572 patch. Implements 21570.
  • Minor bugfix (control protocol):
    • The reply to a "GETINFO config/names" request via the control protocol now spells the type "Dependent" correctly. This is a breaking change in the control protocol. (The field seems to be ignored by the most common known controllers.) Fixes bug 18146; bugfix on
    • The GETINFO extra-info/digest/<digest> command was broken because of a wrong base16 decode return value check, introduced when refactoring that API. Fixes bug 22034; bugfix on
  • Minor bugfix (logging):
    • Don't recommend the use of Tor2web in non-anonymous mode. Recommending Tor2web is a bad idea because the client loses all anonymity. Tor2web should only be used in specific cases by users who *know* and understand the issues. Fixes bug 21294; bugfix on
  • Minor bugfixes (bug resilience):
    • Fix an unreachable size_t overflow in base64_decode(). Fixes bug 19222; bugfix on Found by Guido Vranken; fixed by Hans Jerry Illikainen.
  • Minor bugfixes (build):
    • Replace obsolete Autoconf macros with their modern equivalent and prevent similar issues in the future. Fixes bug 20990; bugfix on
  • Minor bugfixes (certificate expiration time):
    • Avoid using link certificates that don't become valid till some time in the future. Fixes bug 21420; bugfix on
  • Minor bugfixes (client):
    • Always recover from failures in extend_info_from_node(), in an attempt to prevent any recurrence of bug 21242. Fixes bug 21372; bugfix on
    • When clients that use bridges start up with a cached consensus on disk, they were ignoring it and downloading a new one. Now they use the cached one. Fixes bug 20269; bugfix on
  • Minor bugfixes (code correctness):
    • Repair a couple of (unreachable or harmless) cases of the risky comparison-by-subtraction pattern that caused bug 21278.
  • Minor bugfixes (config):
    • Don't assert on startup when trying to get the options list and LearnCircuitBuildTimeout is set to 0: we are currently parsing the options so of course they aren't ready yet. Fixes bug 21062; bugfix on
  • Minor bugfixes (configuration):
    • Accept non-space whitespace characters after the severity level in the `Log` option. Fixes bug 19965; bugfix on
    • Support "TByte" and "TBytes" units in options given in bytes. "TB", "terabyte(s)", "TBit(s)" and "terabit(s)" were already supported. Fixes bug 20622; bugfix on
  • Minor bugfixes (configure, autoconf):
    • Rename the configure option --enable-expensive-hardening to --enable-fragile-hardening. Expensive hardening makes the tor daemon abort when some kinds of issues are detected. Thus, it makes tor more at risk of remote crashes but safer against RCE or heartbleed bug category. We now try to explain this issue in a message from the configure script. Fixes bug 21290; bugfix on
  • Minor bugfixes (consensus weight):
    • Add new consensus method that initializes bw weights to 1 instead of 0. This prevents a zero weight from making it all the way to the end (happens in small testing networks) and causing an error. Fixes bug 14881; bugfix on
  • Minor bugfixes (crash prevention):
    • Fix an (currently untriggerable, but potentially dangerous) crash bug when base32-encoding inputs whose sizes are not a multiple of 5. Fixes bug 21894; bugfix on
  • Minor bugfixes (dead code):
    • Remove a redundant check for PidFile changes at runtime in options_transition_allowed(): this check is already performed regardless of whether the sandbox is active. Fixes bug 21123; bugfix on
  • Minor bugfixes (descriptors):
    • Correctly recognise downloaded full descriptors as valid, even when using microdescriptors as circuits. This affects clients with FetchUselessDescriptors set, and may affect directory authorities. Fixes bug 20839; bugfix on
  • Minor bugfixes (directory mirrors):
    • Allow relays to use directory mirrors without a DirPort: these relays need to be contacted over their ORPorts using a begindir connection. Fixes one case of bug 20711; bugfix on
    • Clarify the message logged when a remote relay is unexpectedly missing an ORPort or DirPort: users were confusing this with a local port. Fixes another case of bug 20711; bugfix on
  • Minor bugfixes (directory system):
    • Bridges and relays now use microdescriptors (like clients do) rather than old-style router descriptors. Now bridges will blend in with clients in terms of the circuits they build. Fixes bug 6769; bugfix on
    • Download all consensus flavors, descriptors, and authority certificates when FetchUselessDescriptors is set, regardless of whether tor is a directory cache or not. Fixes bug 20667; bugfix on all recent tor versions.
  • Minor bugfixes (documentation):
    • Update the tor manual page to document every option that can not be changed while tor is running. Fixes bug 21122.
  • Minor bugfixes (ed25519 certificates):
    • Correctly interpret ed25519 certificates that would expire some time after 19 Jan 2038. Fixes bug 20027; bugfix on
  • Minor bugfixes (fallback directories):
    • Avoid checking fallback candidates' DirPorts if they are down in OnionOO. When a relay operator has multiple relays, this prioritizes relays that are up over relays that are down. Fixes bug 20926; bugfix on
    • Stop failing when OUTPUT_COMMENTS is True in Fixes bug 20877; bugfix on
    • Stop failing when a relay has no uptime data in Fixes bug 20945; bugfix on
  • Minor bugfixes (hidden service):
    • Clean up the code for expiring intro points with no associated circuits. It was causing, rarely, a service with some expiring introduction points to not open enough additional introduction points. Fixes part of bug 21302; bugfix on
    • Resolve two possible underflows which could lead to creating and closing a lot of introduction point circuits in a non-stop loop. Fixes bug 21302; bugfix on
    • Stop setting the torrc option HiddenServiceStatistics to "0" just because we're not a bridge or relay. Instead, we preserve whatever value the user set (or didn't set). Fixes bug 21150; bugfix on
  • Minor bugfixes (hidden services):
    • Make hidden services check for failed intro point connections, even when they have exceeded their intro point creation limit. Fixes bug 21596; bugfix on Reported by Alec Muffett.
    • Make hidden services with 8 to 10 introduction points check for failed circuits immediately after startup. Previously, they would wait for 5 minutes before performing their first checks. Fixes bug 21594; bugfix on Reported by Alec Muffett.
    • Stop ignoring misconfigured hidden services. Instead, refuse to start tor until the misconfigurations have been corrected. Fixes bug 20559; bugfix on multiple commits in and earlier.
  • Minor bugfixes (IPv6):
    • Make IPv6-using clients try harder to find an IPv6 directory server. Fixes bug 20999; bugfix on
    • When IPv6 addresses have not been downloaded yet (microdesc consensus documents don't list relay IPv6 addresses), use hard- coded addresses for authorities, fallbacks, and configured bridges. Now IPv6-only clients can use microdescriptors. Fixes bug 20996; bugfix on b167e82 from 19608 in
  • Minor bugfixes (memory leak at exit):
    • Fix a small harmless memory leak at exit of the previously unused RSA->Ed identity cross-certificate. Fixes bug 17779; bugfix on
  • Minor bugfixes (onion services):
    • Allow the number of introduction points to be as low as 0, rather than as low as 3. Fixes bug 21033; bugfix on
  • Minor bugfixes (portability):
    • Use "OpenBSD" compiler macro instead of "OPENBSD" or "__OpenBSD__". It is supported by OpenBSD itself, and also by most OpenBSD variants (such as Bitrig). Fixes bug 20980; bugfix on
  • Minor bugfixes (portability, also in
    • Avoid crashing when Tor is built using headers that contain CLOCK_MONOTONIC_COARSE, but then tries to run on an older kernel without CLOCK_MONOTONIC_COARSE. Fixes bug 21035; bugfix on
    • Fix Libevent detection on platforms without Libevent 1 headers installed. Fixes bug 21051; bugfix on
  • Minor bugfixes (relay):
    • Avoid a double-marked-circuit warning that could happen when we receive DESTROY cells under heavy load. Fixes bug 20059; bugfix on
    • Honor DataDirectoryGroupReadable when tor is a relay. Previously, initializing the keys would reset the DataDirectory to 0700 instead of 0750 even if DataDirectoryGroupReadable was set to 1. Fixes bug 19953; bugfix on 0.0.2pre16. Patch by "redfish".
  • Minor bugfixes (testing):
    • Fix Raspbian build issues related to missing socket errno in test_util.c. Fixes bug 21116; bugfix on Patch by "hein".
    • Remove undefined behavior from the backtrace generator by removing its signal handler. Fixes bug 21026; bugfix on
    • Use bash in src/test/ This ensures we reliably call chutney's newer tools/ when available. Fixes bug 21562; bugfix on
  • Minor bugfixes (tor-resolve):
    • The tor-resolve command line tool now rejects hostnames over 255 characters in length. Previously, it would silently truncate them, which could lead to bugs. Fixes bug 21280; bugfix on 0.0.9pre5. Patch by "junglefowl".
  • Minor bugfixes (unit tests):
    • Allow the unit tests to pass even when DNS lookups of bogus addresses do not fail as expected. Fixes bug 20862 and 20863; bugfix on unit tests introduced in through
  • Minor bugfixes (util):
    • When finishing writing a file to disk, if we were about to replace the file with the temporary file created before and we fail to replace it, remove the temporary file so it doesn't stay on disk. Fixes bug 20646; bugfix on Patch by fk.
  • Minor bugfixes (Windows services):
    • Be sure to initialize the monotonic time subsystem before using it, even when running as an NT service. Fixes bug 21356; bugfix on
  • Minor bugfixes (Windows):
    • Check for getpagesize before using it to mmap files. This fixes compilation in some MinGW environments. Fixes bug 20530; bugfix on Reported by "ice".
  • Code simplification and refactoring:
    • Abolish all global guard context in entrynodes.c; replace with new guard_selection_t structure as preparation for proposal 271. Closes ticket 19858.
    • Extract magic numbers in circuituse.c into defined variables.
    • Introduce rend_service_is_ephemeral() that tells if given onion service is ephemeral. Replace unclear NULL-checkings for service directory with this function. Closes ticket 20526.
    • Refactor circuit_is_available_for_use to remove unnecessary check.
    • Refactor circuit_predict_and_launch_new for readability and testability. Closes ticket 18873.
    • Refactor code to manipulate global_origin_circuit_list into separate functions. Closes ticket 20921.
    • Refactor large if statement in purpose_needs_anonymity to use switch statement instead. Closes part of ticket 20077.
    • Refactor the hashing API to return negative values for errors, as is done as throughout the codebase. Closes ticket 20717.
    • Remove data structures that were used to index or_connection objects by their RSA identity digests. These structures are fully redundant with the similar structures used in the channel abstraction.
    • Remove duplicate code in the channel_write_*cell() functions. Closes ticket 13827; patch from Pingl.
    • Remove redundant behavior of is_sensitive_dir_purpose, refactor to use only purpose_needs_anonymity. Closes part of ticket 20077.
    • The code to generate and parse EXTEND and EXTEND2 cells has been replaced with code automatically generated by the "trunnel" utility.
  • Documentation (formatting):
    • Clean up formatting of tor.1 man page and HTML doc, where <pre> blocks were incorrectly appearing. Closes ticket 20885.
  • Documentation (man page):
    • Clarify many options in tor.1 and add some min/max values for HiddenService options. Closes ticket 21058.
  • Documentation:
    • Change '1' to 'weight_scale' in consensus bw weights calculation comments, as that is reality. Closes ticket 20273. Patch from pastly.
    • Clarify that when ClientRejectInternalAddresses is enabled (which is the default), multicast DNS hostnames for machines on the local network (of the form *.local) are also rejected. Closes ticket 17070.
    • Correct the value for AuthDirGuardBWGuarantee in the manpage, from 250 KBytes to 2 MBytes. Fixes bug 20435; bugfix on
    • Include the "TBits" unit in Tor's man page. Fixes part of bug 20622; bugfix on
    • Small fixes to the fuzzing documentation. Closes ticket 21472.
    • Stop the man page from incorrectly stating that HiddenServiceDir must already exist. Fixes 20486.
    • Update the description of the directory server options in the manual page, to clarify that a relay no longer needs to set DirPort in order to be a directory cache. Closes ticket 21720.
  • Removed features:
    • The AuthDirMaxServersPerAuthAddr option no longer exists: The same limit for relays running on a single IP applies to authority IP addresses as well as to non-authority IP addresses. Closes ticket 20960.
    • The UseDirectoryGuards torrc option no longer exists: all users that use entry guards will also use directory guards. Related to proposal 271; implements part of ticket 20831.
  • Testing:
    • Add tests for networkstatus_compute_bw_weights_v10.
    • Add unit tests circuit_predict_and_launch_new.
    • Extract dummy_origin_circuit_new so it can be used by other test functions.
    • New unit tests for tor_htonll(). Closes ticket 19563. Patch from "overcaffeinated".
    • Perform the coding style checks when running the tests and fail when coding style violations are found. Closes ticket 5500.

April 27, 2017


Lots of bugfixes, this is much appreciated but a little bit scary!
Wasn't there a plan to rewrite part of Tor, such as bug-prone parsing code, in memory-safe languages? That sounds nicer the more I think about it.


April 28, 2017


>Minor features (geoip):
> Update geoip and geoip6 to the April 4 2017 Maxmind GeoLite2 >Country database.
>Minor features (geoip, also in
> Update geoip and geoip6 to the January 4 2017 Maxmind >GeoLite2 Country database.



April 28, 2017


I worry that RSA 1024 is still somehow used in Tor. Where could I read about all implications of this issue? If attacker stores all traffic and then at some moment find private RSA1024 keys, how much information she can get? Do we have more practical attacks on crypto? If I don't confuse it, essential Tor crypto was moved to ECC many years back, but RSA was still used for some things. One should also mention that many Tor relays use old versions of Tor, so attacks are even more probable.

> I worry that RSA 1024 is still somehow used in Tor. Where could I read about all implications of this issue?

I'm a Tor user. I answer this question according to my understanding, please point mistakes out if I'm wrong.

As far as I know, the only major RSA-1024 usage now, is the Hidden Service private key. This private key determines the ".onion" address and protects hidden services against forgery.

> If attacker stores all traffic and then at some moment find private RSA1024 keys, how much information she can get?

Basically, no information. This key is only used for signing, not data encryption. Actually encryption is done by Curve25519 I think.

If an attacker wants to attack a Hidden Service by exploiting the weakness of RSA-1024, the attacker first need to find out the RSA-1024 private key using massive computational resources, then the attacker needs to hijack the Tor connection of a user in real time, to a fake Hidden Service website. But the attacker is not able to get infomation of previously recorded data.

New version of Hidden Service is still working on progress, hopefully it can be completely within 2017.

> One should also mention that many Tor relays use old versions of Tor.

I think this is the bigger issue.

Well, that one at least is easy. Many people run Debian stable, and the version of Tor in Debian stable is from quite a while ago.

It isn't a security issue (for the relays), since our fine deb maintainer makes sure that it stays up to date on its security things.

But you're right that it can still be a security issue for the clients, since these relays aren't using the newest and greatest Tor designs.

All things considered though, I'm not worried. They're still useful relays, and there's something to be said for stability, and they'll update over time.

Is old version of tor node a bottleneck in the whole tor chain (in sense of security)? Does it downgrade encryption also between other nodes in the chain? If my guard uses old tor crypto which knows nothing about ECC for encryption, does it mean that ECC will not be used in my tor chain at all? (AFAIK, not, am I right?) Does it have sense to restrict the choice of guard nodes only by those which run last stable Tor release?

> If my guard uses old tor crypto which knows nothing about ECC for encryption, does it mean that ECC will not be used in my tor chain at all?

So something that predates 0.2.4.something? It's done on a per hop basis anyway.

> Does it have sense to restrict the choice of guard nodes only by those which run last stable Tor release?

If you want to dramatically reduce your anonymity set, then sure.

It's done on a per hop basis anyway.

Oh, yes, now I've recalled that during transition from RSA to ECC it was required that at least one node in the chain must use ECC.

If you want to dramatically reduce your anonymity set, then sure.

Anonymity is judged on the basis of many effects, each contributing as both partially positive and partially negative for anonymity. Final summary is not always easy to find. E.g. if you know in advance that some nodes are malicious, it is better to remove them from anonymity set.

In the case discussed above, one needs to compare the risks of the cases: 1) Both: my guard is not using ECC and NSA can break RSA in real time. 2) Reduced anonymity set because RSA guards will not be used. Taking into account that guard nodes are quasi-stable (rotated about once in 2 months) answer is not so easy for me. However, once you cannot see any issue here, I think I don't need to interfere with the Tor protocol.

May the old buggy code - ChangeLog! - is a problem, too?

I don't think so. You can remove all files in /var/lib/tor and let tor fetch statistics again. You'll get the same RSA keys.

This is a helpful discussion.

Can I chime in with a question about the Web of Trust for Tails signing keys?

When Tails transitioned to a new signing key (see a few years ago, they said that they would extend the expiration date in one year increments as needed, which has in fact happened. But since about 2016, only anonymous keys which are apparently not listed in the key servers have been used to sign the signing key. Why? Should we be worried that Tails has lost control of their signing key?

TIA for your thoughts!

I think it is offtopic to discuss Tails here, but anyway... I would warry about another thing in Tails. Namely, despite it is assembled from well known opensource projects, the Tails team doesn't publish any instruments to create images by other people. So, if you need to get Tails with some slight modifications, you cannot take build script and patch it. This was true in the past, and I think it still the problem.

Thanks for reply! So, as I've understood, forging of HS key doesn't allow third party to decrypt client's traffic on guard's side (or on nodes from the client's tor chain, i.e. between client and RP or between client and IP) anyway.

Basically, no information. This key is only used for signing, not data encryption.

When I grep /var/lib/tor for RSA keys I find a lot of them in cached-certs, cached-miscrodescs and Suppose, attacker can decrypt RSA1024 in real time, then how much he can do by forging these signatures in tor chain? I guess he can do much, because, otherwise, these signatures would not be used in Tor protocol. Here I speak about usual tor-based clearnet connection, not about HS.

I'm sorry, however, here people en mass asking much more stupid questions about Tor than me. To get answer on this question I need to read heavy docs about protocol and then think about all consequences if something is changed. I guess for you it is much simpler to give me the answer than for me to spend a lot of time to fully understand Tor protocol. I also guess that the answer is pretty simple.

I guess you might be a coder venting at an innocent person because of some frustration in your work. If so, please don't do that in this blog: Tor is far too critical for the safety of ordinary citizens to play games with someone asking a serious question (to which I do not know the answer, unfortunately).

> I guess you might be a coder venting at an innocent person because of some frustration in your work.

You guess wrong.

> Suppose, attacker can decrypt RSA1024 in real time

Then they can break most public key crypto used by Tor, because they have hardware capable of doing large quantum Fourier transforms in excess of what is required to calculate the Elliptic Curve discrete logarithm for a 256 bit curve.

Then they can break most public key crypto used by Tor, because they have hardware capable of doing large quantum Fourier transforms in excess of what is required to calculate the Elliptic Curve discrete logarithm for a 256 bit curve.

I meant attacker can break RSA1024 in real time using classical algorithms, not quantum! The question is not so hypothetical because long time ago there were some proposals of constructing special hardware to break 1024 keys. E.g., this is proposal from 2001:


April 28, 2017


If I were you, I would worry that 'she' might be decrypting ECC in real-time sooner than breaking 1024 keys.
But maybe without the ECC switch we wouldn't have any tor now, 'cos it might have been game over.

Breaking ED25519 sooner than breaking 1024-bit RSA keys?

If you think this is realistic, you should go find a cryptographer and have a chat with them about the state of the art and their predictions for the next few years.

(Here's the short summary for those who don't have a cryptographer handy: ed25519 is one of the strong known ciphers, and 1024-bit RSA is not known to be broken by anybody right now but it's just a matter of years until it is.)

Let me add my 2 coins here. That rumor is pretty old. It was raised because of NSA suddenly issued statement about forcing people to longer keylengths. NSA explained this recommendation as the result of progress in quantum computing. However, many researchers, including Scott Aaronson, are quite skeptical about that. In part, skepticism comes from the fact that NSA doesn't prey on quantum scientists who work in quantum technologies (like it was during Manhattan project). So, some people made conclusion that the real reason of NSA's issue is not progress in quantum computing, but in cryptography of asymmetric systems (also, probably, in ECC).

At that time I've read many opinions about this thing, and didn't find any real point to worry about. Indeed, progress in quantum computing is going, so it could be the real reason in some near future to move to longer case. However, no serious weaknesses in ECC is known, so, taking into account how speedy it is in comparison to long RSA keys (like 4096), I cannot suggest anybody to avoid ECC and prefer RSA.


April 29, 2017


DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.

You're pasting a log line from a Tor Browser. This is a blog post about Tor, and there aren't any Tor Browsers that include Tor So I would say you're off-topic.

That said, that particular log line doesn't mean much of anything. If you're having problems getting your Tor to work, look at the other log lines, not that one.

This is for a standalone build
For a system build for example on debian stable the repository has been: tor-experimental-0.3.0.x-jessie main
On all distributions, last I looked, the latest version is 3.0.5

When 3.0.5 came out within 2-3 days the repository had the available update.
Now, 3 weeks later there is still 3.0.5 and for weeks nobody has responded to the same question, way above on the list. Meanwhile most attempts to use bridges obfs4 either hang or are very slow.

Is this because it is no longer experimental but stable?

Join the discussion...

We encourage respectful, on-topic comments. Comments that violate our Code of Conduct will be deleted. Off-topic comments may be deleted at the discretion of the post moderator. Please do not comment as a way to receive support or report bugs on a post unrelated to a release. If you are looking for support, please see our support portal or ways to get in touch with us.

This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.

3 + 0 =
Solve this simple math problem and enter the result. E.g. for 1+3, enter 4.