- tor-dev - lists.torproject.org

Proposal 328: Make Relays Report When They Are Overloaded
by David Goulet 03 Mar '21

03 Mar '21

Greetings, Attached is a proposal from Mike Perry and I. Merge requsest is here: https://gitlab.torproject.org/tpo/core/torspec/-/merge_requests/22 Cheers! David -- uSxMMaJozH7GAo7qjzhVUm5FDynPYtBfOeZcLS88XeU=

7 12

Best way to reload config on Windows?
by Holmes Wilson 22 Feb '21

22 Feb '21

Hi everyone, We’re building a Ricochet-inspired chat app, and there are situations where we want to create a new hidden service URL. On macOS and Linux we can send a SIGHUP to make Tor reload its config. What’s the best way to do this on Windows? I found an old issue for this (https://gitlab.torproject.org/tpo/core/tor/-/issues/10052 <https://gitlab.torproject.org/tpo/core/tor/-/issues/10052>) but it looks like it never got addressed. Thoughts? Holmes

3 4

Proposal 330: Modernizing authority contact entries
by Nick Mathewson 10 Feb '21

10 Feb '21

(I'm using 330 for this proposal, since 329 is reserved for conflux.) ``` Filename: 330-authority-contact.md Title: Modernizing authority contact entries Author: Nick Mathewson Created: --- Status: Draft ``` This proposal suggests changes to interfaces used to describe a directory authority, to better support load balancing and denial-of-service resistance. (In an appendix, it also suggests an improvement to the description of authority identity keys, to avoid a deprecated cryptographic algorithm.) # Background There are, broadly, three good reasons to make a directory request to a Tor directory authority: - As a relay, to publish a new descriptor. - As another authority, to perform part of the voting and consensus protocol. - As a relay, to fetch a consensus or a set of (micro)descriptors. There are some more reasons that are OK-ish: - as a bandwidth authority or similar related tool running under the auspices of an authority. - as a metrics tool, to fetch directory information. - As a liveness checking tool, to make sure the authorities are running. There are also a number of bad reasons to make a directory request to a Tor directory authority. - As a client, to download directory information. (_Clients should instead use a directory guard, or a fallback directory if they don't know any directory information at all._) - As a tor-related application, to download directory information. (_Such applications should instead run a tor client, which can maintain an up-to-date directory much more efficiently._) Currently, Tor provides two mechanisms for downloading and uploading directory information: the DirPort, and the BeginDir command. A DirPort is an HTTP port on which directory information is served. The BeginDir command is a relay command that is used to send an HTTP stream directly over a Tor circuit. Historically, we used DirPort for all directory requests. Later, when we needed encrypted or anonymous directory requests, we moved to a "Begin-over-tor" approach, and then to BeginDir. We still use the DirPort directly, however, when relays are connecting to authorities to publish descriptors or download fresh directories. We also use it for voting. This proposal suggests that instead of having only a single DirPort, authorities should be able to expose a separate contact point for each supported interaction above. By separating these contact points, we can impose separate access controls and rate limits on each, to improve the robustness of the consensus voting process. Eventually, separate contact points will allow us do even more: we'll be able to have separate implementations for the upload and download components of the authorities, and keep the voting component mostly offline. # Adding contact points to authorities Currently, for each directory authority, we ship an authority entry. For example, the entry describing tor26 is: "tor26 orport=443 " "v3ident=14C131DFC5C6F93646BE72FA1401C02A8DF2E8B4 " "ipv6=[2001:858:2:2:aabb:0:563b:1526]:443 " "86.59.21.38:80 847B 1F85 0344 D787 6491 A548 92F9 0493 4E4E B85D", We extend these lines with optional contact point elements as follows: - `upload=http://IP:port/` A location to publish router descriptors. - `download=http://IP:port/` A location to use for caches when fetching router descriptors. - `vote=http://IP:port/` A location to use for authorities when voting. Each of these contact point elements can appear more than once. If it does, then it describes multiple valid contact points for a given purpose; implementations MAY use any of the contact point elements that they recognize for a given authority. Implementations SHOULD ignore url schemas that they do not recognize, and SHOULD ignore hostnames addresses that appear in the place of the IP elements above. (This will make it easier for us to extend these lists in the future.) If there is no contact point element for a given type, then implementations should fall back to using the main IPv4 addr:port, and/or the IPv6 addr:port if available. As an extra rule: If more than one authority lists the same upload point, then uploading a descriptor to that upload point counts as having uploaded it to all of those authorities. (This rule will allow multiple authorities to share an upload point in the future, if they decide to do so. We do not need a corresponding rules for voting or downloading, since every authority participates in voting directly, and since there is no notion of "downloading from each authority.") # Authority-side configuration We add a few flags to DirPort configuration, indicating what kind of requests are acceptable. - `no-voting` - `no-download` - `no-upload` These flags remove a given set of possible operations from a given DirPort. So for example, an authority might say: DirPort 9030 no-download no-upload DirPort 9040 no-voting no-upload DirPort 9050 no-voting no-download We can also allow "upload-only" as an alias for "no-voting no-download", and so on. Note that authorities would need to keep a legacy dirport around until all relays have upgraded. # Bridge authorities This proposal does not yet apply to bridge authorities, since neither clients nor bridges connect to bridge authorities over HTTP. A later proposal may add a schema that can be used to describe contacting to a bridge authority via BEGINDIR. # Example uses ## Example setup: Simple access control and balancing. Right now the essential functionality of authorities is sometimes blocked by getting too much load from directory downloads by non-relays. To address this we can proceed as follows. We can have each relay authority open four separate dirports: One for publishing, one for voting, one for downloading, and one legacy port. These can be rate-limited separately, and requests sent to the wrong port can be rejected. We could additionally prioritize voting, then uploads, then downloads. This could be done either within Tor, or with other IP shaping tools. ## Example setup: Full authority refactoring In the future, this system lets us get fancier with our authorities and how they are factored. For example, as in proposal 257, an authority could run upload services, voting, and download services all at separate locations. The authorities themselves would be the only ones that needed to use their voting protocol. The upload services (run on the behalf of authorities or groups of authorities) could receive descriptors and do initial testing on them before passing them on to the authorities. The authorities could then vote with one another, and push the resulting consensus and descriptors to the download services. This would make the download services primarily responsible for serving directory information, and have them take all the load. # Appendix: Cryptographic extensions to authority configuration The 'v3ident' element, and the relay identity fingerprint in authority configuration, are currently both given as SHA1 digests of RSA keys. SHA1 is currently deprecated: even though we're only relying on second-preimage resistance, we should migrate away. With that in mind, we're adding two more fields to the authority entries: - `ed25519-id=BASE64` The ed25519 identity of a the authority when it acts as a relay. - `v3ident-sha3-256=HEX` The SHA3-256 digest of the authority's v3 signing key. (We use base64 here for the ed25519 key since that's what we use elsewhere.)

1 0

Proposed changes to Tor long-term-support (LTS) policy
by Nick Mathewson 04 Feb '21

04 Feb '21

Hi, all! I've been working on a proposed change to Tor's LTS policies. I've run it by a few people already, and now I'm posting it here for wider comment. (summary: If we decide to do this, we will still be able to do LTS releases, but we will backport fewer things to them, and we will make fewer promises about how well they will work on the network.) ===================== # Background and summary: I'm proposing a change to Tor's long-term support (LTS) policies. For reference, our current policy is described at https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/CoreTorRele… We've been struggling with our LTS policies for a while. In brief: we backport too many fixes, and we promise too much support for LTS releases. The developers don't like it, because the amount of things that we keep trying to fix in our LTS releases keeps us working on old crufty code for a long time. Many packagers don't like it, because they have a policy of auditing security backports, and we backport too much to our LTS releases for them to audit carefully. And our network maintenance group doesn't like it, because our commitment to supporting very old protocol versions keeps us from implementing performance and security improvements on a rapid schedule, unless we backport those changes to the LTS releases. Therefore, we're going to propose these changes: - That once a release becomes LTS-only, its code no longer gets anything but security patches (narrowly defined), and minimal patches to keep it working on the network. - We will no longer guarantee that an LTS-only release will work (or work well) on the mainline Tor network for its entire LTS lifetime. We'll try to deliver this if we can, but it won't be a definite guarantee. # In more detail We propose the following release statuses: - Development. (Every series starts out in this state as an alpha.) - Stable. (Once a series is officially 'ready', we call it stable.) - Old-stable. (Every supported stable release, except the most recent one, is in this state.) - Long-term support only. (Any LTS release, once a newer release has become old-stable. Only certain releases will get LTS support.) Every series starts out in "development". Once it's officially ready, we call it "stable". All stable releases besides the most recent one are "old-stable". Allowed in all releases: - Updates to authorities list - Updates to fallbackdirs list - Updates to geoip database LTS-only (any LTS release, once an newer release is oldstable): - Only two kinds of changes are allowed: - Security fixes, narrowly defined. (See below for a definition.) - _Simple_ patches that keep the release functional on the network. - Relays are not guaranteed to be supported on the network, although we'll try not to remove them gratuitously. - Clients and onion services are not guaranteed to work on the network, although we'll try not to break them gratuitously. In other words, with an LTS release there will be no guarantee that the software works on the network. The promise is that we will keep it working on the network when we can do so with simple low-risk patches, and that _if_ it works, we will fix security problems in it. Oldstable (All stable releases besides the most recent stable release): - Stability fixes are also allowed. - Relays will be supported on the network. - Clients and onion services will be supported on the network. - Dirauths may be supported. Stable (The single most recent stable release): - All fixes are allowed. - Relays will be supported on the network. - Clients and onion services will be supported on the network. - Dirauths will be supported. Development: - All fixes are allowed. - Relays will be supported on the network. - Clients and onion services will be supported on the network. - Dirauths will be supported. ============================== What is a security fix? - It is a _bugfix_ that resolves a vulnerability. _Features_ that make Tor more private, anonymous, or more secure won't count. ============================== The LTS policy above will apply to 0.3.5 _starting with 0.3.5.14_, since we've already made backports that will appear in 0.3.5.13. We have already committed to making 0.3.5 an LTS release until Feb 1, 2022. We also now commit to making 0.4.5 an LTS release until _at least_ Feb 15, 2023. Whether we continue to do this LTS for longer will depend on our experiences with this new policy. ============================== So, any proposed amendments to this? best wishes, -- Nick

1 0

(no subject)
by Jithin S 02 Feb '21

02 Feb '21

Hi, I have recently started running a TOR node with the nickname *CostlyOnion2. *At the time of writing of this email, the details of the node are as follows: *Uptime*: 14 days 3 hours 18 minutes and 0 second *Advertised Bandwidth*: 3.35 MiB/s *Flags*: *Fast Running Stable V2Dir Valid* *First Seen*: 2021-01-18 17:00:00 (14 days 19 hours 13 minutes and 32 seconds) *Last Restarted*: 2021-01-19 08:55:32 For current details, click here <https://metrics.torproject.org/rs.html#details/19EDB4798A4C170D603F86D8862B…> . My concern is how soon we will get a Guard status for our relay. I have read this <https://blog.torproject.org/lifecycle-new-relay> blog post regarding the life cycle of a relay. As it says, for a relay aged 8-68 days to get "Guard" status, we need to keep an eye on three factors *viz. *bandwidth, weighted fractional uptime, and time known. Suppose we keep running the relay all the time with the above-mentioned bandwidth(3.35 MiB/s), I would like to know about following - How long it will take to get the guard status? - My link bandwidth is quite high (close to 50MBytes/s), still the advertised is around 3.35MiB/s. What could be the possible factors for this? - As I am doing some analysis studies, we would also like to know what all factors we should take into account for the users to make use of our relay? I also request you to share any relevant resources for getting more information regarding the above questions, especially on the calculation of consensus weight. Thanks and regards, Jithin S

1 0

Relay stalling when creating circuits
by Andreas Kempe 24 Jan '21

24 Jan '21

Hello everyone! For a while now, I've noted that when running a non-exit relay under fairly heavy load that is allowed to be utilised as a client, it has a tendency to stall when trying to create new circuits. If the relay has not been used as a client for a while and has a need to create new circuits, CPU load shoots up to 100 % and the stalls for some amount of time. I've seen stalls of over 1 minute. I've taken two profiling traces of the relay, one during normal operations and during the stalling behaviour. This was done on version 0.4.4.6 and each profile is approximately a 10 second recording. Normal case: >- 84,34% event_base_loop > - 80,19% event_process_active_single_queue > - 42,87% scheduler_evt_callback > - 42,86% kist_scheduler_run > + 20,23% connection_handle_write > + 9,47% update_socket_info_impl > + 5,07% channel_flush_some_cells > + 2,49% smartlist_pqueue_pop > + 2,19% outbuf_table_add > + 1,06% smartlist_pqueue_add > + 28,38% conn_read_callback > - 5,27% periodic_event_dispatch > - 3,32% second_elapsed_callback > + 1,69% run_connection_housekeeping > + 0,98% circuit_build_needed_circs > + 1,73% save_state_callback > + 1,50% conn_write_callback > + 1,02% connection_ap_attach_pending > + 4,02% epoll_dispatch Stalling case: >- 86,27% event_base_loop > - 85,52% event_process_active_single_queue > - 31,78% periodic_event_dispatch > - 30,00% second_elapsed_callback > - 28,84% circuit_build_needed_circs > - 15,35% connection_ap_attach_pending > - 15,34% connection_ap_handshake_attach_circuit > - 15,34% circuit_get_open_circ_or_launch > 10,14% circuit_get_best > - 4,99% circuit_launch_by_extend_info > - 4,88% circuit_establish_circuit > + 2,11% router_choose_random_node > + 2,05% nodelist_add_node_and_family > 0,69% count_acceptable_nodes.isra.0 > + 13,39% circuit_launch_by_extend_info > + 0,80% run_connection_housekeeping > + 1,74% save_state_callback > - 30,76% connection_ap_attach_pending > - connection_ap_handshake_attach_circuit > - 30,74% circuit_get_open_circ_or_launch > - 30,63% circuit_get_best > 1,18% circuit_get_global_list > + 11,50% conn_read_callback > + 10,47% scheduler_evt_callback > - 10,47% scheduler_evt_callback > - kist_scheduler_run > + 6,27% connection_handle_write > + 1,54% channel_flush_some_cells > + 0,98% update_socket_info_impl > + 0,91% smartlist_pqueue_pop > 0,75% epoll_dispatch (The traces above are meant to be indented for legibility, but some mail clients think they know better.) Has anyone seen similar behaviour or have an inkling as to what's going on? I thought it best to ask before diving into the code. Cordially, Andreas Kempe

1 0

DirAuth usage and 503 try again later
by James 20 Jan '21

20 Jan '21

Good day. Is there any chance that torpy (https://github.com/torpyorg/torpy) was triggered this issue https://gitlab.torproject.org/tpo/core/tor/-/issues/33018 ? Some wary facts: - Torpy using old fashion consensus (not mircodesc) - When consensus not present in cache (first time usage) it downloads consensus from random directory authorities only. - Before August 2020 it was using plain HTTP requests to DirAuths. Now it creates "CREATE_FAST" circuits to DirAuths (is that right way by the way?) From other side: - Torpy store consensus on disk (so whenever client restart it must not download full consensus again) - It will try download consensus after time which sets by valid_time field from consensus which more than 1 hour (so it's not so often) - Torpy try get consensus by "diff" feature (so it's minimize traffic) Still may be some of this features not working well in some conditions. Which could cause a lot of consensus downloads in Jan 2020... Or may be you know more info about this situation? Do you have some recommendations for tor client implementation? Can you explain in several paragraphs what behavior of original tor client is? As far as I understand when first time original tor starts it tries download consensus from fallback dirs not from DA? Is this key point? There is one more issue https://gitlab.torproject.org/tpo/core/tor/-/issues/40239 which I'm not understand correctly. Let's imagine it's first run of tor client and that time coincidentally coincided with DA voting. That means client will not be able to download consensus? That is strange decision. Or do you mean clients must download consensus from fallback dirs which never in "voting" process?

4 6

torify/nmap results in SIGABRT
by Peng Yu 15 Jan '21

15 Jan '21

Hi, I see the following error. Is it a bug in torify/torsocks? Thanks. $ torify nmap -p7 google.com ... NSOCK ERROR [88.9380s] nsock_make_socket(): Socket trouble: Operation not permitted Assertion failed: (nse->iod->sd >= 0), function nsock_pool_add_event, file nsock_core.c, line 1273. Abort trap: 6 -- Regards, Peng

2 1

Has Core Tor Development Slowed? Or Are We Moving To Rust/arti?
by Neel Chauhan 09 Jan '21

09 Jan '21

Hi tor-dev@, I hope you all had a great holiday season. I noticed that Core Tor development, especially with the tor daemon, has slowed down significantly since the COVID crisis. Sorry if I have been less active in the Tor community as opposed to the past. I've been more focused on FreeBSD Ports as of now, but I still want to post at least the occasional Tor patch here and there. Core Tor/Tor hasn't seen an update since December 21, even when we are already a week into 2021. Is this related to the layoffs which happened last year? Or is Tor moving to Rust (via arti) and all the development is happening there? I'm guessing both. If it's the latter, I guess I have to start learning Rust sooner rather than later. Well, who am I kidding, I had to learn C# and PowerShell for my job (Disclaimer: I work at Microsoft, not on security or Windows/Azure however). Is there any other reason? Best, Neel Chauhan

3 2

TOP SECRET BULLETIN ABOUT THE RACCOON EFFECT
by The23rd Raccoon 24 Dec '20

24 Dec '20

Was the Raccoon ACTUALLY RIGHT after ALL THESE YEARS: Proof of a SOLO CUTTING EDGE PARADIGM SHIFT, or an ALIEN INTERVENTION to EXPOSE ACADEMIC CONSPIRACY? by Raccoon23 (You'll have to excuse my caps lock: I am going for a world record high score on the crackpot index[1,2]. Cypherpunk lore has a loooong history of high scores in this index, so I really do have to work very hard to get every point I reasonably can. However, I'm already at 226 points in the title, by my count. Plus I've got this[3] going for me, which is nice.) But enough about that. Let's get to the meat[4]! Recent advances in traffic analysis defenses have finally proved that my controversial but revolutionary theories[5,6] are valid, overturning decades of theories about traffic analysis attacks against anonymity networks! Ok ok, so I might have made a mistake in the math[7]. But I'm just a Raccoon who reads discarded academic research papers in a dumpster. While I have been highly educated through my dumpster schooling, one can't expect raccoons to do math correctly. Such math is best left to others who can properly express my theory in terms of equations. Others like Panchenko, Pulls, Danezis, Kadianakis, et al; and maybe Perry. (But probably not Perry.) I have worked on this problem *alone* for many years, while I was in or around many highly respected mental institutions. I was even cautioned to take a break, by my therapeutic advisors. Probably because I was getting too close to the TRUTH! However, as we shall see, this was not entirely a solo effort. This leaves only one possibility: ALIEN INTERVENTION[8]. But before we get to that, much has happened since my two posts on this topic, over a decade ago. So let's recap: My two posts were written in opposition to the orthodox view that anonymity networks would always be 100% broken by traffic correlation attacks, and so therefore side channels such as cryptographic tagging attacks were not worth including in Tor's threat model. Paul Syverson, the famous self-appointed defender of the orthodoxy of onion routing, argued most vigorously against my points, carefully trying to correct me. But I would not be dissuaded! (I love you Paul! Just scoring crackpot points.) Paul's clout with the "scientific establishment" is clearly very strong. Paul has had a distinguished career, being named in The Foreign Policy Top 100 Global Thinkers List in 2012[9], and named an ACM Fellow in 2014[10]. As evidence of his obvious involvement in the scientific conspiracy against me, consider that my original post was cut short "somehow" on the official Tor Project mailing list archive[11], compared to the original[5]. This is also not the first time a famous thinker has suppressed an idea that they secretly believed in. Elon Musk, renowned and respected former proponent of the Simulation Hypothesis[12], clearly knows that optimized versions of the Alcubierre Drive[13] are realizable using excess exotic matter accumulated during particle accelerator "downtime". Downtime, I might add, that is facilitated by a Tor Project volunteer administrator who goes by the codename 'weasel', who subsequently faked his own death to avoid implication[14]. These are the kinds of people we are dealing with here. They will stop at NOTHING to conceal the TRUTH! Elon has since begun a cover-up of the Simulation Hypothesis[15], presumably because someone collected his bounty to help him escape The Matrix[16]. Despite all of this being so obviously exposed, Elon still pursues his wasteful and foolish rocketry! Merely because he likes lighting things on fire[17], digging tunnels[18], and playing with electricity[19]. Elon, the raccoons can relate -- we just wish you would come clean, and admit you did it all for the tunnel rave... Anyway, I digress. Some time after my post, I would learn from my daily dumpster deliveries that Website Traffic Fingerprinting had became a fad in academic research circles. Website Traffic Fingerprinting is a form of traffic analysis that uses machine learning to recognize website access over Tor, by observing only the encrypted traffic patterns entering the Tor network. For ethical and practical reasons, these attacks are performed in lab conditions on researcher generated web crawls, often using individual static web page access, rather than involving interactive user web browsing or other concurrent Tor activity common to real-world Tor usage. Mike Perry, a suspiciously private employee of the Tor Project, critiqued the limitations of these lab conditions, and questioned the accuracy of many of these attacks in realistic settings[20]. Perry and Kadianakis also developed a framework for building traffic analysis defenses for Tor[21]. Despite this, or perhaps because of it, a long series of attacks and defenses ensued, and the advent of deep learning[22] caused many to believe that defenses against deep learning based Website Traffic Fingerprinting attacks were as hopeless as trying to defend against end-to-end correlation. I watched from my dumpster as these hidebound reactionary responses to traffic analysis defenses continued for many years, seemingly trying to bait me out of hiding, to no avail[23]. (To be honest, I don't even know what hidebound means. I'm just a raccoon. But saying that gets me crackpot points. And it totally happened!) However, I was eventually delighted to see that some recent advances by others had arrived in my dumpster, finally allowing my ideas to have vindication! Recently, Panchenko et al found traffic splitting to be highly effective against state of the art Website Traffic Fingerprinting attacks based on deep learning[24]. Concurrently, Tobias Pulls used Perry and Kadianakis's padding machines in an optimization problem, using a Genetic Algorithm to evolve optimal padding machines against deep learning classifiers, for use in defense against Website Traffic Fingerprinting[25]. With this result, we have finally entered the age of the machines versus the machines. Raccoon math, while groundbreaking, is no longer necessary. Both of these defenses were highly successful on their own. However, with the combination of traffic splitting and cover traffic defenses, Tor will be on the CUTTING EDGE of making a PARADIGM SHIFT in its threat model, to tackle the hardest problem of all: END-TO-END TRAFFIC CORRELATION. Allow me to present my case: Einstien once posited that time was relative. While Einstien's theory of relativity was fundamentally misguided, time is relative. Relative to the problem of both end-to-end traffic correlation, and Website Traffic Fingerprinting. Einstien, in his later years, even alluded to quantum observation correlation as "spooky action at a distance", setting precedent for the connection that I have known all along to be true. Einstien might not have been as insightful as me, but for all his fumbling, Einstien was right about one thing: correlation attacks *are* spooky. Metadata kills people[26]. (Sadly, that is not a joke...) Unfortunately, Einstien's results were incomplete, and his groping to unify these problems was not properly understood by any, except yours truly. Deep learning was so successful at Website Traffic Fingerprinting that most researchers did not even bother to provide their deep learning classifiers with time-based features. They claimed their classifiers were accurate enough without considering time at all! We now know this to be false, thanks to the independent discoveries of new defenses by the teams of Panchenko and Pulls. As it turns out, quantum mechanics is also fundamentally misguided. We now know that the universe appears to be made up of fragments of energy at a fundamental level[27]. In fact, after all these years, raccoons and their allies (alien or otherwise) seem to be almost as close to unifying physics as we are to addressing end-to-end correlation in Tor! Indeed, once time is included as a feature, deep learning based Website Traffic Fingerprinting attacks will effectively be correlating the timing and traffic patterns of websites to their representations in its neural model. This model comparison is extremely similar to how end-to-end correlation compares the timing and traffic patterns of Tor entrance traffic to Tor exit traffic. In fact, deep learning classifiers have already shown success in correlating end-to-end traffic on Tor[28]. Some say that Long Term Statistical Disclosure (LTSD) attacks will still always win the end-to-end correlation game against anonymity networks, in the fullness of time[29]. However, LTSD attacks are only a theory. And much like quantum mechanics, relativity, and LSD, these attacks also warp one's perception of reality, time, and space. All of these theories are fundamentally misguided. LTSD attacks predict that over time, correlation gradually leaks enough information to fully deanonymize users of anonymity networks. But also much like quantum mechanics, they fail to fully define the mechanism. Consider this thought experiment (feel free to use whatever mind expanding devices you have at hand to assist you): LTSD assumes that an adversary has complete high resolution information of all traffic that enters and exits an anonymity network. Additionally, LTSD assumes that an adversary has identifiers available to properly track traffic streams on *each* side of the correlation, over the full duration of observation and long-term correlation. Several real-world effects undermine these assumptions. Widespread deployment of HTTPS[30], the trend towards encrypted DNS and SNI, shared cloud infrastructure, and the practical infeasibility of full Internet-wide traffic record keeping, all reduce the ability of the adversary to track repeated connections over time. Additionally, defenses that multiplex traffic entering the Tor network with traffic splitting and cover traffic undermine the adversary's ability to fully determine traffic time and quantity information that pertains to specific connections. All of this means that the LTSD adversary, much like Einstien's light-riding cowboy and Schrodinger's cat, remain an idealized approximation of reality. Despite the results of the DeepCorr experiment[28], from this thought experiment, it is clear that correlation can be mitigated, perhaps even pushing long-term correlation attacks into time durations that allow for many practical use cases, even web browsing. As we know from the historical record[31], aliens need anonymity too[32]. And when their hyper-dimensional cats join with all of the raccoons[33] and other creatures who are using Tor on a regular basis, the quantity of co-incident events (and unmatched pairs due to to incomplete observation) will rise high enough to cause LTSD to require larger and larger amounts of observation time, to perform effective correlation. This by itself is a huge win. We can now say with certainty that The Raccoon Effect has thoroughly discromulated correlation attacks. (Discromulation is my term to describe what this kind of defense does. Most interestingly, I am forced into winning this crackpot point. Because deep learning is an opaque machine generated attack, and because the GA-optimized defense is also machine generated, it is actually impossible to precisely describe the complete behaviors of either one, other than with the resulting model definitions themselves! Brave new world.) Now, what about alien intervention? Well, assuming we do not consider the AI that participated in this work to be alien: if aliens did intervene, none would argue the discromulating conflugruity of The Raccoon Effect. Unfortunately however, I can neither confirm nor deny these allegations[34], at this time[35]. But that's not all! Since the circuit padding framework is implemented in Tor, this means that it is covered by Tor's bug bounty. While research papers that break padding defenses are not covered by the bounty (especially if those defenses are not actually deployed), there *is* in fact prize money for any flaws found in the framework that could lead to code execution, or deanonymization[36]. In conclusion: Here I am, setting a world record high score on the crackpot index (despite many admirable high scores by previous cypherpunks), and I was RIGHT ALL ALONG. I deserve a Nobel Prize for this work. But I do not expect to get one. I expect the brownshirts and Nazis embedded in the scientific establishment to continue to work hard to suppress my TRUTH. Even the crackpot index itself is involved in this conspiracy of scientific suppression. John Baez, the creator of the crackpot index, would surely confirm this, if he was not also part of the conspiracy against me! I have included him on CC, just in case he would like to recant his suppression of my original thinking, before his show trial. Like Galileo, I will cede no ground in this Inquisition! In fact, much like myself, even Newton struggled through a pandemic[37], and prevailed. We are more alike than you know. Newton tossed apples to many a raccoon in his garden. That's how we taught him to poorly approximate gravity (even though his misguided and simple calculus was barely up to the task). In these tough times, it is very satisfying to finally have vindication. As the Base Rate Fallacy showed all those years ago: The Raccoon Effect is real. THEY are watching; but WE are Legion[38]. Unfortunately, the reproducibility crisis in science is also real. More than ten years later, it is *still* often hard to reproduce, confirm, and compare results across the various papers that end up in my dumpster. Venues that do not have artifact archival policies are, in fact, on the verge of becoming shams. I am glad that some venues, and some researchers, are recanting the old ways[39,40]. The paper is not the only product of good research! P.S. You'll have to keep this all much more secret than I did. I don't want anyone to steal these ideas; the aliens might get upset. 2020 is not over! P.P.S. This sentence gets me #4. (As a liar's paradox[41]). Some say this puts me in a superposition of both getting and not getting #4, and I inherently can't get those points in this way. But I say that should get me double points! (And thus earn more points for #5). Gotta collect 'em all. P.P.P.S. At 1004 points on the crackpot index, I believe this post is now the highest scoring publication with a valid novel idea that has been written, to date[2]. P.P.P.P.S. Fucking bored as fuck during this fucking pandemic. Fuck![42] 1. https://math.ucr.edu/home/baez/crackpot.html 2. https://www.reddit.com/r/math/comments/4r05wh/has_anyone_with_a_high_crackp… 3. https://en.m.wikipedia.org/wiki/Betteridge%27s_law_of_headlines 4. http://www.stinkymeat.net/ 5. https://archives.seul.org/or/dev/Mar-2012/msg00019.html - Raccoon23 Post1 6. https://archives.seul.org/or/dev/Sep-2008/msg00016.html - Raccoon23 Post2 7. https://conspicuouschatter.wordpress.com/2008/09/30/the-base-rate-fallacy-a… 8. https://fahrplan.events.ccc.de/congress/2006/Fahrplan/speakers/1242.en.html 9. https://awards.acm.org/award_winners/syverson_5067587 10. https://web.archive.org/web/20121130072122/http://www.foreignpolicy.com/art… 11. https://lists.torproject.org/pipermail/tor-dev/2008-September/002493.html 12. https://en.wikipedia.org/wiki/Simulation_hypothesis#The_simulation_argument 13. https://en.wikipedia.org/wiki/Alcubierre_drive 14. https://www.bbc.com/news/world-europe-36173247 - Weasel takes down LHC 15. https://www.slashgear.com/elon-musk-has-banned-hot-tub-talks-about-simulate… 16. https://www.forbes.com/sites/janetwburns/2016/10/13/elon-musk-and-friends-a… 17. https://www.youtube.com/watch?v=qLcma0YyzhY - Elon Musk Flame Thrower 18. https://www.yogonet.com/international/noticias/2020/12/07/55695-boring-comp… 19. https://www.inverse.com/innovation/tesla-electric-jet-3-4-years-away 20. https://blog.torproject.org/critique-website-traffic-fingerprinting-attacks 21. https://github.com/torproject/tor/blob/master/doc/HACKING/CircuitPaddingDev… 22. https://arxiv.org/pdf/1801.02265.pdf - Deep Fingerprinting Tor 23. https://www.youtube.com/watch?v=TvjMr6DU7C8 - Raccoon call 24. https://www.comsys.rwth-aachen.de/fileadmin/papers/2020/2020-delacadena-tra… 25. https://arxiv.org/abs/2011.13471 - Pulls GA Defense 26. https://abcnews.go.com/blogs/headlines/2014/05/ex-nsa-chief-we-kill-people-… 27. https://www.full-thesis.net/fragments-of-energy-not-waves-or-particles-may-… 28. https://people.cs.umass.edu/~amir/papers/CCS18-DeepCorr.pdf 29. https://www.freehaven.net/anonbib/cache/statistical-disclosure.pdf 30. https://transparencyreport.google.com/https/overview?hl=en 31. https://en.wikipedia.org/wiki/Accelerando#Characters 32. https://fahrplan.events.ccc.de/congress/2006/Fahrplan/attachments/1167-Spea… 33. https://www.youtube.com/watch?v=jSRfIMjvtFk - Raccoons and cats <3 34. https://edition.cnn.com/2020/04/27/politics/pentagon-ufo-videos/index.html 35. https://www.nbcnews.com/news/weird-news/former-israeli-space-security-chief… 36. https://hackerone.com/torproject 37. https://www.msn.com/en-ie/news/coronavirus/during-a-pandemic-isaac-newton-h… 38. https://www.youtube.com/watch?v=Ofp26_oc4CA - Raccoons are Legion 39. https://www.usenix.org/conference/usenixsecurity21/artifact-evaluation-info… 40. https://petsymposium.org/artifacts.php 41. https://en.wikipedia.org/wiki/Liar_paradox 42. https://www.youtube.com/watch?v=04_rIuVc_qM - WTF For Karsten: https://cs5.livemaster.ru/storage/3a/1f/1449eb23f3c3b318ab4960815fn4--water…

2 2