- tor-dev - lists.torproject.org

ahmia ~ summer of privacy
by Stelios Barberakis 24 Apr '18

24 Apr '18

Hello all, My name is Stelios and I am a CS student at Technical University of Crete. This summer I will be working on ahmia <https://ahmia.fi> project, during the "summer of privacy". This will be the first time to be engaged with the tor-ecosystem community as a developer, and I am really glad about it. The current plan includes some updates, enhancements of the codebase and the building/deployment process (including docker), as well as some new features like search filters, but we are looking to come up with new ideas for additional features, etc. Everyone is welcomed to contribute to the brainstorming, so feel free to ask anything you would like, either here or by joining #ahmia channel in OFTC if you feel so. I will do my best to contribute this summer, and hopefully beyond that. I will be sending bi-weekly reports to @tor-dev, so that everyone could be informed about the progress. Best Regards, Stelios -- PGP key: http://keyserver.ubuntu.com/pks/lookup?op=get&search=0xBF6EA91B7CBE3998

2 2

HS desc replay protection and ed25519 malleability
by George Kadianakis 24 Apr '18

24 Apr '18

Hello Ian, isis, and other crypto people around here! Here is an intro: In HSv3 we've been using revision counters (integers++) to do HS desc replay protection, so that bad HSDirs cannot replay old descs to other HSDirs. We recently learned that this is a bad idea from a scalability prespective (multiple sites need to track rev counter...), and also it's needless complexity in the code (tor needs to cache the counters etc.). See ticket #25552 for more details: https://trac.torproject.org/projects/tor/ticket/25552 https://gitweb.torproject.org/torspec.git/tree/rend-spec-v3.txt#n1078 In #25552 we've been making plans to ditch the rev counters and replace them with a casual replay cache. (These replay caches also don't need to be big, since descriptors are only replayable for a day before the ephemeral blinded key changes, and the cache can be reset). Anyhow, now we've been playing the game of "which part of the desc should we use in the replay cache"? The latest plan here has been to use the ed25519 descriptor signature since it's something small, simple and necessarily changes with every fresh descriptor. And this is how we entered the ed25519 malleability scene. The basic question here is, can we use the ed25519 signature in our replay cache and consider it immutable by attackers without the private key? And should we use R, or S, or both? According to RFC8032: Ed25519 and Ed448 signatures are not malleable due to the check that decoded S is smaller than l. Without this check, one can add a multiple of l into a scalar part and still pass signature verification, resulting in malleable signatures. However, neither donna or ref10 include such a check explicitly IIUC. Instead they check whether (RS[63] & 224), which basically ensures that the high 3 bits of S are zeroed, which ensures S < 2^253. Is that equivalent to the RFC check? Because if I'm counting right, for most legit S values you can still add a single l as the attacker and get an S' = S + l < 2^253 equivalent signature (you can't add 2*l tho). So what's the state of ed25519 malleability? I know that after the Bitcoin incident, people have thought about this a lot, so I doubt we are in a broken state, but I just wanted to make sure that we will not mess something up. :) Thanks for the help! :)

5 7

Tor Messenger
by Milan Damjanovic 24 Apr '18

24 Apr '18

Hello, I would like to ask is there any online documentation about how is possible to transmit text messages via tor nodes? I would like to [try to] rewrite the TorChat Messenger which is written in Python 2.7 and wxPython to Python 3x and Qt. I cant find any documents how to transmit messages between two tor nodes so anything would be helpful... Cheers, Milan

2 2

Simple Bandwidth Scanner is now open source
by Matt Traudt 23 Apr '18

23 Apr '18

https://github.com/pastly/simple-bw-scanner Simple Bandwidth Scanner (sbws) aims to replace torflow[0], the bandwidth measuring software bwauths use today. For the most up to date documentation about how it works and why it exists, see the docs at readthedocs, especially the spec[2][3]. sbws's semantic version (currently 0.1.0) should not be considered meaningful until 1.0.0. There are major planned changes to how it works (the HTTPS milestone[1]), and likely a few unplanned changes too. I haven't put much thought into whether sbws should canonically live on gitweb.tpo or on GitHub other than I like GitHub's issue tracking, milestones, Travis CI integration, and readthedocs integration. So it might move ... or it might not. Cheers Matt [0]: https://gitweb.torproject.org/torflow.git [1]: https://github.com/pastly/simple-bw-scanner/milestone/3 [2]: https://sbws.readthedocs.io/en/latest/specification.html [3]: http://d7pxflytfsmz6uh3x7i2jxzzwea6nbpmtsz5tmfkcin5edapaig5vpyd.onion/speci…

1 0

Bandwidth scanner - Summer of Privacy
by juga 23 Apr '18

23 Apr '18

Hi, I will be working on the bandwidth scanner project during the Tor Summer of Privacy. This would include implementing features to the scanner code, writing tests and documentation, deployment in a test network, comparing results, modify little-tor code. The goal is to have bandwidth scanner code that is easier to maintain, understand, run and gives better measurements. There will be more details online and with reports. I've being already contributing on this project, for instance, writing a draft specification for the bandwidth measurements format [0] or reporting/fixing bugs on bwscanner code [1]. I'm MS in computer engineering, senior developer and have worked as sysadmin and researcher. Best regards, juga. GnuPG key fp: 2DA81D01455C3A0032198850F305447AF806D46B [0] https://lists.torproject.org/pipermail/tor-dev/2018-April/013071.html [1] https://github.com/TheTorProject/bwscanner

1 0

Notes from 19 April 2018 Simple Bandwidth Scanner Meeting
by Matt Traudt 19 Apr '18

19 Apr '18

Next meeting is scheduled 26 April 2018 at 2200 UTC in #tor-meeting, **BUT** we are probably going to look into finding a time that works better across three halves of the globe. Pad is here, and is copy/pasted below. https://pad.riseup.net/p/BenwGdgpz0uS Meeting IRC log http://meetbot.debian.net/tor-meeting/2018/tor-meeting.2018-04-19-21.59.log… Simple Bandwidth Scanner meeting 19 April 2018 ============================================== Previous weeks notes: https://lists.torproject.org/pipermail/tor-dev/2018-April/013059.html Updates -------------------------------------------------------- pastly: - Started running an authority in the test net. Don't think it's working yet and/or people have started trusting it - Switched to standard python logging module - Added periodic reachability tests for helper relays - (Helped) add FAQ and glosasry to docs - Learned: no part of sbws is CPU bound. Weird results were due to a helper that is not capable of much bandwidth - Time is still passing. In less than 2w the open source paperwork should be back next week: - Put docs on an onion service - Ask dirauths what they want to do about sbws servers In the coming weeks, I think I need to be transitioning away from "big" feature type stuff that isn't absolutely necessary, and instead focus my time on docs, tests, and making sbws easy to use. I think literal next steps need to include a practice deployment and transition in the testnet. It's one thing to run an sbws scanner and server. I've done that. I want to see other people try it so we can learn what isn't obvious to anyone but me. I want to exercise getting scan results to the dirauth so it can put them in the consensus. i've tried scanner and server and reported problems :) * list tasks for next months: https://pad.riseup.net/p/bfikl6PM0YV9 * plan proposed by teor with testnet deployment: * ... * it'll be very useful to have sbws doc public! juga: last week: * 1st draft spec * setup dirauth, sbws server, sbws scanner * dirauth not yet in consensus * start doc about what we have deployed so far (started to feel a bit lost about what we have/need) * added draft faq and glossary to doc next week: * finish spec * check the status of config files vs cli args, with debug (sorry pastly, didn't follow close the changes) and see whether #91 is really needed * check the status of tests/chutney * implement actually some unit test? * think how to make easier deployment at some point and add something on it? (cron/Makefile/system services?) questions: * pastly: once sbws repo is public, can we work on new releases publicly? [pastly: says yes] teor: last week: * occasional suggestions this week: * make my test dirauth a trust pastly's and juga's dirauths * eventually try to set up sbws on the testnet

1 0

Proposal: The move to two guard nodes
by Mike Perry 18 Apr '18

18 Apr '18

In-line below for ease of comment. Also available at: https://gitweb.torproject.org/user/mikeperry/torspec.git/tree/proposals/xxx… =========================== Filename: xxx-two-guard-nodes.txt Title: The move to two guard nodes Author: Mike Perry Created: 2018-03-22 Supersedes: Proposal 236 0. Background Back in 2014, Tor moved from three guard nodes to one guard node[1,2,3]. We made this change primarily to limit points of observability of entry into the Tor network for clients and onion services, as well as to reduce the ability of an adversary to track clients as they move from one internet connection to another by their choice of guards. 1. Proposed changes 1.1. Switch to two guards per client When this proposal becomes effective, clients will switch to using two guard nodes. The guard node selection algorithms of Proposal 271 will remain unchanged. Instead of having one primary guard "in use", Tor clients will always use two. This will be accomplished by setting the guard-n-primary-guards-to-use consensus parameter to 2, as well as guard-n-primary-guards to 2. (Section 3.1 covers the reason for both parameters). This is equivalent to using the torrc option NumEntryGuards=2, which can be used for testing behavior prior to the consensus update. 1.2. Enforce Tor's path restrictions across this guard layer In order to ensure that Tor can always build circuits using two guards without resorting to a third, they must be chosen such that Tor's path restrictions could still build a path with at least one of them, regardless of the other nodes in the path. In other words, we must ensure that both guards are not chosen from the same /16 or the same node family. In this way, Tor will always be able to build a path using these guards, preventing the use of a third guard. 2. Discussion 2.1. Why two guards? The main argument for switching to two guards is that because of Tor's path restrictions, we're already using two guards, but we're using them in a suboptimal and potentially dangerous way. Tor's path restrictions enforce the condition that the same node cannot appear twice in the same circuit, nor can nodes from the same /16 subnet or node family be used in the same circuit. Tor's paths are also built such that the exit node is chosen first and held fixed during guard node choice, as are the IP, HSDIR, and RPs for onion services. This means that whenever one of these nodes happens to be the guard[4], or be in the same /16 or node family as the guard, Tor will build that circuit using a second "primary" guard, as per proposal 271[7]. Worse still, the choice of RP, IP, and exit can all be controlled by an adversary (to varying degrees), enabling them to force the use of a second guard at will. Because this happens somewhat infrequently in normal operation, a fresh TLS connection will typically be created to the second "primary" guard, and that TLS connection will be used only for the circuit for that particular request. This property makes all sorts of traffic analysis attacks easier, because this TLS connection will not benefit from any multiplexing. This is more serious than traffic injection via an already in-use guard because the lack of multiplexing means that the data retention level required to gain information from this activity is very low, and may exist for other reasons. To gain information from this behavior, an adversary needs only connection 5-tuples + timestamps, as opposed to detailed timeseries data that is polluted by other concurrent activity and padding. In the most severe form of this attack, the adversary can take a suspect list of Tor client IP addresses (or the list of all Guard node IP addresses) and observe when secondary Tor connections are made to them at the time when they cycle through all guards as RPs for connections to an onion service. This adversary does not require collusion on the part of observers beyond the ability to provide 5-tuple connection logs (which ISPs may retain for reasons such as netflow accounting, IDS, or DoS protection systems). A fully passive adversary can also make use of this behavior. Clients unlucky enough to pick guard nodes in heavily used /16s or in large node families will tend to make use of a second guard more frequently even without effort from the adversary. In these cases, the lack of multiplexing also means that observers along the path to this secondary guard gain more information per observation. 2.2. Why not MOAR guards? We do not want to increase the number of observation points for client activity into the Tor network[1]. We merely want better multiplexing for the cases where this already happens. 2.3. Can you put some numbers on that? The Changing of the Guards[13] paper studies this from a few different angles, but one of the crucially missing graphs is how long a client can expect to run with N guards before it chooses a malicious guard. However, we do have tables in section 3.2.1 of proposal 247 that cover this[14]. There are three tables there: one for a 1% adversary, one for a 5% adversary, and one for a 10% adversary. You can see the probability of adversary success for one and two guards in terms of the number of rotations needed before the adversary's node is chosen. Not surprisingly, the two guard adversary gets to compromise clients roughly twice as quickly, but the timescales are still rather large even for the 10% adversary: they only have 50% chance of success after 4 rotations, which will take about 14 months with Tor's 3.5 month guard rotation. 2.4. What about guard fingerprinting? More guards also means more fingerprinting[8]. However, even one guard may be enough to fingerprint a user who moves around in the same area, if that guard is low bandwidth or there are not many Tor users in that area. Furthermore, our use of separate directory guards (and three of them) means that we're not really changing the situation much with the addition of another regular guard. Right now, directory guard use alone is enough to track all Tor users across the entire world. While the directory guard problem could be fixed[12] (and should be fixed), it is still the case that another mechanism should be used for the general problem of guard-vs-location management[9]. 3. Alternatives There are two other solutions that also avoid the use of secondary guard in the path restriction case. 3.1. Eliminate path restrictions entirely If Tor decided to stop enforcing /16, node family, and also allowed the guard node to be chosen twice in the path, then under normal conditions, it should retain the use of its primary guard. This approach is not as extreme as it seems on face. In fact, it is hard to come up with arguments against removing these restrictions. Tor's /16 restriction is of questionable utility against monitoring, and it can be argued that since only good actors use node family, it gives influence over path selection to bad actors in ways that are worse than the benefit it provides to paths through good actors[10,11]. However, while removing path restrictions will solve the immediate problem, it will not address other instances where Tor temporarily opts use a second guard due to congestion, OOM, or failure of its primary guard, and we're still running into bugs where this can be adversarially controlled or just happen randomly[5]. While using two guards means twice the surface area for these types of bugs, it also means that instances where they happen simultaneously on both guards (thus forcing a third guard) are much less likely than with just one guard. (In the passive adversary model, consider that one guard fails at any point with probability P1. If we assume that such passive failures are independent events, both guards would fail concurrently with probability P1*P2. Even if the events are correlated, the maximum chance of concurrent failure is still MIN(P1,P2)). Note that for this analysis to hold, we have to ensure that nodes that are at RESOURCELIMIT or otherwise temporarily unresponsive do not cause us to consider other primary guards beyond than the two we have chosen. This is accomplished by setting guard-n-primary-guards to 2 (in addition to setting guard-n-primary-guards-to-use to 2). With this parameter set, the proposal 271 algorithm will avoid considering more than our two guards, unless *both* are down at once. 3.2. No Guard-flagged nodes as exit, RP, IP, or HSDIRs Similar to 3.1, we could instead forbid the use of Guard-flagged nodes for the exit, IP, RP, and HSDIR positions. This solution has two problems: First, like 3.1, it also does not handle the case where resource exhaustion could force the use of a second guard. Second, it requires clients to upgrade to the new behavior and stop using Guard flagged nodes before it can be deployed. 4. The future is confluxed An additional benefit of using a second guard is that it enables us to eventually use conflux[6]. Conflux works by giving circuits a 256bit cookie that is sent to the exit/RP, and circuits that are then built to the same exit/RP with the same cookie can then be fused together. Throughput estimates are used to balance traffic between these circuits, depending on their performance. We have unfortunately signaled to the research community that conflux is not worth pursuing, because of our insistence on a single guard. While not relevant to this proposal (indeed, conflux requires its own proposal and also concurrent research), it is worth noting that whichever way we go here, the door remains open to conflux because of its utility against similar issues. If our conflux implementation includes packet acking, then circuits can still survive the loss of one guard node due to DoS, OOM, or other failures because the second half of the path will remain open and usable (see the probability of concurrent failure arguments in Section 3.1). If exits remember this cookie for a short period of time after the last circuit is closed, the technique can be used to protect against DoS/OOM/guard downtime conditions that take down both guard nodes or destroy many circuits to confirm both guard node choices. In these cases, circuits could be rebuilt along an alternate path and resumed without end-to-end circuit connectivity loss. This same technique will also make things like ephemeral bridges (ie Snowflake/Flashproxy) more usable, because bridge uptime will no longer be so crucial to usability. It will also improve mobile usability by allowing us to resume connections after mobile Tor apps are briefly suspended, or if the user switches between cell and wifi networks. Furthermore, it is likely that conflux will also be useful against traffic analysis and congestion attacks. Since the load balancing is dynamic and hard to predict by an external observer and also increases overall traffic multiplexing, traffic correlation and website traffic fingerprinting attacks will become harder, because the adversary can no longer be sure what percentage of the traffic they have seen (depending on their position and other potential concurrent activity). Similarly, it should also help dampen congestion attacks, since traffic will automatically shift away from a congested guard. References: 1. https://blog.torproject.org/improving-tors-anonymity-changing-guard-paramet… 2. https://trac.torproject.org/projects/tor/ticket/12206 3. https://gitweb.torproject.org/torspec.git/tree/proposals/236-single-guard-n… 4. https://trac.torproject.org/projects/tor/ticket/14917 5. https://trac.torproject.org/projects/tor/ticket/25347#comment:14 6. https://www.cypherpunks.ca/~iang/pubs/conflux-pets.pdf 7. https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-… 8. https://trac.torproject.org/projects/tor/ticket/9273#comment:3 9. https://tails.boum.org/blueprint/persistent_Tor_state/ 10. https://trac.torproject.org/projects/tor/ticket/6676#comment:3 11. https://bugs.torproject.org/15060 12. https://trac.torproject.org/projects/tor/ticket/10969 13. https://www.freehaven.net/anonbib/cache/wpes12-cogs.pdf 14. https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-disco… -- Mike Perry

4 7

[release] [protocol] Onionoo 6.0-1.13.0 and metrics-lib 2.3.0
by iwakeh 18 Apr '18

18 Apr '18

Hi there! Two new releases are available at: https://dist.torproject.org/onionoo/6.0-1.13.0/ https://dist.torproject.org/metrics-lib/2.3.0/ This Onionoo release provides the announced major version change to 6.0 Protocol change (also summarized in [0], [1]): Change the "exit_addresses" field to not exclude current OR addresses anymore. This release also includes some bug fixes, please take a look at the change log [2]. The changes are already deployed on all onionoo.torproject.org instances. The new metrics-lib release adds support for reading web server logs contained in tar-archives and a backwards compatible API change detailed in the changelog [3] and described in the javadoc documentation [4]. Please direct comments and questions to the metrics-team mailing list [5]. Cheers, iwakeh [0] https://metrics.torproject.org/onionoo.html#versions_6_0 [1] https://metrics.torproject.org/onionoo.html#details_relay_exit_addresses [2] https://gitweb.torproject.org/onionoo.git/plain/CHANGELOG.md [3] https://gitweb.torproject.org/metrics-lib.git/plain/CHANGELOG.md [4] https://metrics.torproject.org/metrics-lib/org/torproject/descriptor/Server… [5] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team

1 0

Tor Bandwidth Measurements Document Format
by juga 17 Apr '18

17 Apr '18

Hi, as commented with teor and pastly, i send in-line a draft specification for the document format that the bandwidth scanner implementations should produce. I've left my own questions/notes in square brackets. Thanks, juga. ======================================= Tor Bandwidth Measurements Document Format [juga: which name should we give to this document?] 1. Scope and preliminaries This document describes the format of Tor's bandwidth measurements document, version X.X.X [juga: which version should be this?] and later. Since Tor version X.X.X [juga: which tor version?] the directory authorities use the bandwidth measurements document called "V3BandwidthsFile" and produced by Torflow [1] (format described in README.spec.txt [2]). The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1.2. Acknowledgements The original bandwidth measurement scanner (Torflow) and format was created by mike. Teor suggested to write this specification while contributing on pastly's new bandwidth scanner implementation. This specification was revised after feedback from: XXX 1.3 Outline The bandwidth measurements mentioned in sections 3.4.1 and 3.4.2 of dir-spec.txt [3] are obtained by bandwidth authorities, which are either directory authorities or other servers running bandwidth measurement scanners and sending the results to the former. [juga: it seems that bandwidth authorities have not been formally before] 2. Format details Bandwidth measurements MUST contain the following sections: - Header (exactly once) - Relays measurements (zero or more times) Each section (or entry) ends with a separator. 2.1. Nonterminals The following nonterminals are defined in the Onionoo details document specification [4]: fingerprint nickname In the bandwidth measurement documents nickname is optional. The following nonterminals are defined in the in dir-spec.txt: NL (newline) SP (space) "bw" = INT, the aggregated measured bandwidth of this relay, in kilobytes per second. We introduce the following nonterminals: [juga: this should probably be defined more formally and should probably link to other documents, which ones?] "version" = The name and the version of the bandwidth scannner software, such as "sbws 0.1.0". The name of the software, if absent, is assumed to be "torflow". [juga: which should be the version if absent?] "timestamp" = INT, the Unix Epoch time when the file was created. 2.2. Header format It MUST consists of: "timestamp" timestamp NL "version" version NL 2.3. Relay measurements format Relays measurements MUST consist of the following items. "node_id" fingerprint SP "bw" bandwidth SP When there are no more items, the "bw" item ends with NL instead of SP. 2.4. Optional extra items Different implementations of the bandwidth measurements scanners MAY include other items per relay. For instance, sbws includes: "rtt" = INT, Round Trip Time (to obtain 1B) Every relay measurement in sbws consists of: "node_id" fingerprint SP "bw" bandwidth SP "nick=" nickname SP "rtt=" rtt SP "time=" timestamp NL Every relay measurement in Torflow consists of: "node_id" fingerprint SP "bw" bandwidth SP "nick=" nickname SP "measured_at=" slice timestamp NL The "measured_at" does not correspond to the "time" in sbws. [juga: actually, if bwauths use "measured_at", then the code on them or sbws should be changed]. Torflow includes other items that are out of the scope of this document. References: 1. https://gitweb.torproject.org/torflow.git 2. https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/… 3. https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt 4. https://metrics.torproject.org/onionoo.html#details A. Sample data A.1. Torflow 1523911758 node_id=$68A483E05A2ABDCA6DA5A3EF8DB5177638A27F80 bw=392760 nick=Test measured_at=1523911725 updated_at=1523911725 pid_error=4.11374090719 pid_error_sum=4.11374090719 pid_bw=57136645 pid_delta=2.12168374577 circ_fail=0.2 scanner=/filepath A.2. sbws 1523911758 version=0.1.0 node_id=$68A483E05A2ABDCA6DA5A3EF8DB5177638A27F80 bw=392760 nick=Test rtt=380 time=1523911725

2 1

Hogging of second_elapsed_callback()
by Linus Nordberg 15 Apr '18

15 Apr '18

Hi, How long time can we spend signing status documents before tor gets sad? I ask because I'm planning on putting dirauth signing keys on a sloooooow HSM and would like to understand if I'd have to make format_networkstatus_vote() and networkstatus_compute_consensus() (and their callers) be "restartable", much like dirvote_act() is "restartable". Current measurements indicate a worst case figure of 6.5 seconds for a hashing and signing operation. This may even increase some over time. (It may also shrink considerably with some optimisations but this is where we are today.)

2 2