- tor-dev - lists.torproject.org

Proposal: Tor with collective signatures
by Nicolas Gailly 03 May '16

03 May '16

Hi all, Since the first post, I've received some comments off-list and consequently added more sections to the proposal. Particularly, it adds a detailed description of the messages that needs to be passed down between the witnesses, paragraphs to answer some questions, and a link to the official paper. I hope it gets clearer and answer most of your questions :) Please, feel free to ask questions on/off list, I'd be happy to discuss about it anytime ;) (irc: nikkolasg) Thanks, Nicolas version 0.2: - 3.2.1 Setup : explicitly using Fallback directory mirrors as witnesses - 3.2.2 Operation: what does a witness that refuse to sign do - 3.2.3 added incremental deployment section - 3.3 : added evolution of the CoSi set of witnesses section - 3.1 added signature description - 5 Specifications: 5.1: Protocol 5.2: Format ------------------------------------------------------------------------------------------ Filename: tor_cosi.txt Title: Tor Cosi Author: Nicolas GAILLY, DeDiS lab, EPFL Created: 09.03.2016 Status: draft Version: 0.2 0. Introduction This document describes how to provide and use a decentralized witness cosigning mechanism in order to gain proactive transparency and public accountability for the Tor consensus documents. Directory Authorities (DA) send their document to this set of witnesses and embed the signature within the document. Tor relays and clients can choose to refuse a consensus document if it has not been accepted and signed by a threshold of witnesses. 1. Overview A weakness of the current DA system is that if any 5 of the 9 DAs’ keys are stolen or coerced they could be used to sign fake directories that the attacker might use secretly in another part of the world to compromise Tor clients in the attacker’s domain. We propose to address this class of attacks by incorporating decentralized witness cosigning (CoSi) into the directory signing process, which ensures that any consensus document must be not only signed by appropriate DAs, but also publicly witnessed, signed and logged by a larger group of servers acting as witnesses, before clients will accept the directory. A Tor relay or client expects to receive an additional "CoSi" signature alongside the consensus document. They verify if the signature is correct and whether a sufficient number of witnesses attested that the consensus document is valid or not. The Tor project would fix such a threshold in the default configuration but any user or relay is free to adjust this value to its own need. In order to verify the signature, they need to have the individuals public keys of all the witnesses beforehand. This "CoSi certificate" can be embedded in the software in the same way certificate pinning does. 2. Motivation Tor's DAs are comprised of 9 servers (and one extra for the bridges): four of them are in the US and 5 of them are in the EU. Attacking these central and vital points of the Tor network is clearly within the reach of state level adversaries if they were to collaborate. Recent stories about surveillance show that such a collaboration is already happening. For example, let's imagine a plausible situation where a state-level attacker secretly coerces and/or steals the private keys of 5 of the 9 DAs, takes them back to the Republic of Tyrannia where they control the ISPs and the country’s Internet connectivity to the rest of the world. The government embeds those keys in their “Great Firewall” type devices, and uses them to secretly MITM attack targeted Tor users within Tyrannia by giving them correctly-signed but completely false views of the Tor directory in which all of the available relays are run by the Tyrannian authorities. Since this attack does not attack the consensus documents that the legitimate DAs are regularly broadcasting to the rest of the world, neither the Tor project nor anyone else outside of Tyrannia will have the opportunity to see or become aware of the fake consensus documents, and not many people even inside Tyrannia might have the opportunity to detect the attack if it is carefully targeted against the small number of suspected activists and journalists the government does not like. The main goal of CoSi applied in Tor should be to ensure consensus document transparency: that is, ensure the property that any consensus document that any Tor client anywhere will accept has been observed and logged by a significant number of parties throughout the world, so that any misuse of a quorum of 5 DA keys anywhere will be quickly detectable (soon, if not necessarily during the signing process itself). 3. Design The first part will talk more about the architecture of a "CoSi" system and the second part will go into more detail about how such a system can be integrated in Tor. For more details, please refer to the official paper [0]. 3.1 Simplified Architecture The designated leader arranges all the witnesses in a tree. The public keys of each participants are aggregated to form an aggregate public key. The tree is only there for performance reasons and can be reconfigured at any point in time without affecting security (the latest experiments showed that we could run up to 8000 nodes with a 2 second delay for generating a signature). Once the tree is constructed, its "certificate" represents the aggregate public key and all its individual public keys of each witnesses. At the end of a signature round, the client will be able to verify the CoSi signature (which uses Schnorr signatures) using the aggregate public key. A CoSi signature have two components: - Schnorr signature - Exceptions: bitmap of length equal to the size of the witness group used by absent witnesses or refusing-to-sign witnesses (see 3.2.2 Operations). Besides contributing to the signing, each witness can and should perform any readily feasible syntactic and semantic correctness checks on the leader’s proposed statements before signing off on them. They can / should probably publish logs of the statements they witness or simply make available a public mirror of everything that its tree roster has been asked to sign. 3.2 CoSi in Tor 3.2.1 Setup CoSi relies on a list of decentralized cosigning witnesses, an optional role to be supported by a future version of the standard Tor relay software. The set of witness servers will initially be defined as the D.A. and a subset of the Fallback Directory Mirrors [2], namely the set of relays that are (a) deemed stable enough by the same criteria as used for selecting Fallback Directory Mirrors, (b) are running a recent enough version of the Tor relay software to support the CoSi witness server role, and (c) have not opted out of playing this CoSi witness role. That way the deployment cost is drastically reduced as software will already have the keys to verify a CoSi signature. Another criteria for the tree construction includes the latency between witnesses. One can collect information about the communication latencies between the witnesses and construct a shortest-path spanning tree using this data in order to reduce the global latency of the system. 3.2.2 Operations Once the tree is setup and each one knows about it (have the certificate), then the signature process happens for each consensus document. The CoSi protocol produces a collective signature in response to the initiation of the protocol by a leader. This signature is then included in the consensus document so clients don't have to request it from another party. If a witness does not want to sign, it toggles the bit at its index in the bitmap. Its index is determined as the index in the list of witnesses from the CoSi certificate. The client will then see a "1" bit in the bitmap, and will subtract the corresponding public key of the witness from the aggregate public key. That way, the client is still able to verify the signature and it knows about which witnesses refused to sign off. The mechanism is similar for witnesses that went offline. The parent of an offline witness will set the bit in the bitmap of the failed witness. One issue for discussion is who should initiate CoSi protocol rounds and at what times. For example, each of the 9 DAs (or whatever subset is online) could independently initiate CoSi rounds on each directory consensus event, producing up to nine separate, redundant collective signatures on each directory consensus. Alternatively, the common case might be for one of the 9 DAs to be the CoSi initiator at a given time, with a round-robin leader-change mechanism ensuring that another leader takes over if the prior one becomes unavailable. A related issue for discussion is whether it could be problematic if there are two or more distinct collective signatures for a given directory consensus, and whether it is a problem if distinct subsets of 5 DAs might (perhaps accidentally) produce multiple slightly different, though valid and legitimately-signed, consensus documents at about the same time. In other words, does Tor directory consensus “need” strong consistency with a single serialized timeline, as Byzantine consensus protocols are intended to provide - or is weak consistency with occasional cases of multiple concurrent consensus documents and/or collective signatures acceptable? 3.2.3 Integration First of all, integrating CoSi would *not* immediately affect the fundamental structure or function of the current DAs: there could still be 9 of them, of which any 5 can authorize the release of a new consensus document, as they do now. Secondly, CoSi would not necessarily change anything about how the 9 DAs decide on how to compute these directory consensus documents; e.g., it would not prevent the DAs from working together to block the inclusion of (or assignment of bandwidth-weight to) relays that might be perceived by the DAs as doing bad things. Finally, full backward compatibility with old Tor clients and relay software may be maintained by treating the new CoSi-generated collective signature as just an additional signature that gets attached to and distributed with consensus documents. It may be treated as a special “10th virtual DA” that does not help authorize decisions but just publicly witnesses the output of the regular 9 DAs. Old client and relay software can simply ignore that new collective signature, whereas new software might look for it and over time gradually increase the threshold number of witnesses it expects to see. For incremental deployment purposes, it's reasonable to think that those Fallback Directory mirrors servers probably would not deply CoSi support all at the same time. Moreover, this set of witnesses might be a subset of the Fallback Directoy mirrors and some of them would not want to be cosigners. The hard-coded list of mirrors into the Tor client might need to be annotated with a “cosigner flag" for each such mirror, allowing some bootstrap relays to be cosigners and others not. The witness group is then simply the subset of fallback directory mirrors with the cosigner flag set. 3.3 Evolution of the CoSi set of witnesses One obvious solution for the evolution of the CoSi set of winesses lies into the version-ing mechanism of Tor. A particular Tor client version would be associated with a particular cosigning group which consists of the D.A. and the Fallback Directory Mirrors whose keys are embedded into the source code of this Tor version with this "cosigner flag" set. A client will have the latest CoSi set keys when and only when its Tor client would be upgraded - just like the list of directory authorities. 3.4 Optional: Break-the-glass Emergency Directory Adjustments In case of emergency, the delay caused by having to coordinate among 5 DAs in order to make anything happen (i.e. excluding a set of malicious nodes) can be problematic. This section proposes a mechanism in which the CoSi witnesses can accept and witness not just “full consensus” documents (signed by 5 DAs), but can also accept “emergency adjustments”, which are highly-constrained deltas (diffs) to an existing full consensus document signed by a smaller threshold of DAs, e.g., 2 or even just 1. For example, the CoSi witness cosigning rules might require that an emergency directory-adjustment must: - be a diff against a “fresh”, recent full consensus document (perhaps *the* most recent one), - can make no modifications to the full consensus other than some pre-defined operations such as decreasing bandwidth weights assigned to relays, - cannot affect the directory-wide total bandwidth weight by more than X% (e.g., 1% or .1%). These suggestions are just a few imaginable rules to get the idea across; the “right” rules would of course need much more discussion. This way, if one or two DAs discovers or even strongly suspects an attack of some kind, they can take emergency countermeasures against the attack and be able to roll them out to clients quickly without having to get a full 5 DAs out of bed - but because the delta-consensus is still witness-cosigned automatically by (perhaps) all the DAs and a number of additional trusted relays, we get the strong accountability provision that the use of such a “break-the-glass” emergency provision will immediately become known to the other DAs as soon as they do get out of bed. Such a break-the-glass emergency adjustment mechanism could be designed, if desired, so that ordinary clients and relays cannot immediately tell the difference between a directory consensus produced via the normal threshold of 5 DAs and one that was produced as a delta via the emergency adjustment mechanism. Only the witness cosigners would necessarily need to know which collectively-signed directories were authorized via the full consensus procedure or via a break-the-glass adjustment. So if it’s important to keep it secret from the general public the precise reason for a particular directory update, that can be accommodated. Only the more-trusted group of witness cosigners (and obviously all the DAs themselves) would necessarily know the precise origin and administrative justification of a given directory update. With even fancier crypto, even the witnesses would not necessarily need to know, but that’s beyond the scope of this proposal and its desirability may be questionable at any rate. 4. Security implications 4.1 Cons Since the structure is a tree, if any node fails, there must be some failover mechanisms to restore connectivity between the children of the failed node and the rest of the tree. Since the DA reach consensus every hour [1], with the help of the gossiping network, the availability problem is not an issue. 4.2 Benefits Technically, it is quite easy to implement witness cosigning if the group of witnesses is small. If we want the group of witnesses to be large, however – and we do, to ensure that compromising transparency would require not just a few but hundreds or even thousands of witnesses to be colluding maliciously – then gathering hundreds or thousands of individual signatures could become painful and inefficient. Worse, every client would need to check all these signatures individually. The key technical contribution of our research is a distributed protocol that makes large, decentralized witness cosigning groups practical. This decentralized approach enables the security of the whole system to scale with the number of witnesses. Not only does this system dramatically increase the cost of successfully deploying an attack on the DA (the attacker would have to corrupt a large majority of the witnesses), it also decreases the incentive to launch such an attack because the threshold of witnesses that are required to sign the document for the signature to be accepted can be locally set on each client. 4.3 Differences between CoSi and Certificate Transparency Prior transparency mechanisms have two weaknesses. First they do not significantly increase the number of secret keys an attacker must control to compromise any client device, and client devices cannot even retroactively detect such compromise unless they can actively communicate with multiple well-known Internet servers. For example, even with Certificate Transparency, an attacker can forge an Extended Validation (EV) certificate for Chrome after compromising or coercing only three parties: one Certificate Authority (CA) and two log servers. Since many CAs and log servers are in US jurisdiction, such an attack is clearly within reach of the US government. If such an attack does occur, Certificate Transparency cannot detect it unless the victim device has a chance to communicate or gossip the fake certificate with other parties on the Internet – after it has already accepted and started using the fake digital certificate. In the case of Tor Transparency, the attack is harder because the attacker would have to compromise the three parties plus a majority of Directory Authorities but facing a state-level adversary the threat is still plausible. One way to increase the difficulty of the attack is to make sure the logs servers are scattered in different places of the world. Second, the attacker can still evade transparency by controlling the client’s Internet access paths. For example, a compromised Internet service provider (ISP) or corporate Internet gateway can defeat retroactive transparency mechanisms by persistently blocking a victim device’s access to transparency servers elsewhere on the Internet. Even if the user’s device is mobile, a state intelligence service such as China’s “Great Firewall” could defeat retroactive transparency mechanisms by persistently blocking connections from a targeted victim’s devices to external transparency servers, in the same way that China already blocks connections to many websites and Tor relays. Using CoSi requires the clients to have the list of public keys of all the witnesses embedded in the software, like certificate pinning. In order to reduce the size of this CoSi certificate, we embed the aggregated public key of all the witnesses and a hash representing the root of a Merkle tree containing the public key of all the witnesses. Using the certificate this way provides an universally-verifiable commitment to all the witnesses’ public keys, without the certificate actually containing them all. 5. Specifications 5.1 Protocol We will describe quickly the protocol here; for a more detailed explanation, please refers to the academic paper [0]. The setup is as described in 3.2.1. The protocol in itself consists of four phases: - Announcement: The leader broadcast down the consensus document to its children, which in turn also broadcast to their children,etc. - Commitment: When the leaves of the CoSi tree get the consensus document, generate its random value v(i) and the corresponding commitment V(i) and sends V(i) up to its parent. If a leaf refuses to sign this consensus document, it does not create any commitment. Each intermediate node aggregate all the commitments of their children, add their own commitment (or nothing if it refuses to sign) and send the result up in the tree. The root gets the aggregated commitment V of all signing witnesses. - Challenge: The root then compute the challenge c = H( m || V ), with m being the consensus document and H being a collision resistant hash function that returns a scalar, and distribute the challenge down the tree like in the Announcement phase. - Response: Starting from the leaves, each witnesses compute its response r(i) = v(i) - c * x(i), where x(i) is the long term private key of the witness. If the witness refuses to sign, it simply set the n-th bit of the bitmap to "1", where n is the index of the witness in the "CoSi certificate" (the list of all individual public keys). Each intermediate nodes in the tree aggregate the responses and the bitmap of all its children, aggregate with its own response/bitmap and send that up in the tree. At the end of the protocol, the root gets the aggregated response r. The signature is the tuple (c,r) and must be included in the consensus document. If no exceptions occurred (i.e. the bitmap contains all "0"s), the signature can be verified using the aggregate public key of all witnesses using standard Schnorr verification algorithm [3]. If an exception occurs, the client needs to lookup the indexes where the bitmap contains "1"s. The client then lookup the corresponding public keys (from the list of public keys of witnesses) and subtract each of them from the aggregate public key. The client can then use this reduced public key to verify the signature as usual. 5.2 Format + The "CoSi certificate" is a list of all witnesse's ed25519 public keys and the aggregate public key of all individual public keys. Please note that while the current implementation only uses ed25519, it is completely possible to use any other elliptic curve implementations. + A CoSi signature contains: - the challenge c, an ed25519 scalar - the response r, an ed25519 scalar - the bitmap of exceptions, whose length is equal to the number of witnesses. + The messages sent during the four following phases are as follow: - Announcement: consensus document - Commitment: an ed25519 curve point - Challenge: an ed25519 scalar - Response: an ed25519 scalar and the exception bitmap 6. Compatibility 7. Implementation Implementation in Go is open source at: https://github.com/dedis/cothority 8. Performance 9. Acknowledgements This proposals has received some valuable feedback from Bryan Ford, Linus Gasser, Ismail Khoffi, Philipp Jovanovic, and Ludovic Barman. A. References [0] http://arxiv.org/pdf/1503.08768v3.pdf [1] https://collector.torproject.org [2] https://trac.torproject.org/projects/tor/wiki/doc/FallbackDirectoryMirrors [3] https://en.wikipedia.org/wiki/Schnorr_signature

3 6

Summer of Privacy Application | Rohit Dua
by Rohit Dua 30 Apr '16

30 Apr '16

Hi I recently knew about this years Tor summer of code. Although the date of application is gone, I would like to ask if I could still manage to get into the program. I'm interested in working on Tor technology. If not officially with the summer of code, could I work as an remote intern in any of the projects which were not chosen by other selected students for summer of code. I have previously successfully completed Google Summer of Code with Mediawiki in 2014 and The Honeynet Project in 2015. Currently I'm in my final year of college. If any such thing is possible please let me know, I will send my proposal right away. Waiting for your reply Rohit Dua Delhi, India

3 2

Private Tor Research Network
by Nicholas R. Parker (RIT Student) 30 Apr '16

30 Apr '16

Hi all, I've got an issue that I'm seeking help with. I'm with a small group out of RIT that's trying to construct a private TOR network for research purposes, but we've hit a bit of a snag. I've worked with both liu fengyun's ( http://liufengyun.chaos-lab.com/prog/2015/01/09/private-tor-network.html) and Ritter's write up (https://ritter.vg/blog-run_your_own_tor_network.html) but when trying to set up authority directories the whole thing really falls apart. Trying to edit the torrc file gives errors where it doesn't attempt to bind to the correct ports and trying to set --dirserver or --datadirectory results in errors that there isn't permission to access /var/lib/tor regardless of the owner of the directory (we've tried leaving it as being owned by _tor, tried changing ownership to root, etc) so we can't get the authority directories off the ground. I'd really appreciate any thoughts Nicholas R. Parker Rochester Institute of Technology 5thYear, BS/MS Computing Security

2 5

Quantum-safe Hybrid handshake for Tor
by Zhenfei Zhang 29 Apr '16

29 Apr '16

Hi list, This is a proposal to use quantum-safe hybrid handshake for Tor communications. Given NSA's recent announcement on moving towards quantum-safe cryptography, it would be nice to have a quantum-safe feature for Tor. The idea of the quantum-safe hybrid handshake is to combine both classical key exchange and a key encapsulation mechanism (KEM) instantiated by a quantum safe encryption algorithm, so that the combination gives both (classical) authentication and quantum safety. In a bit more details, the client and the server agrees on a classic pre-master secret, $c$, using the ntor protocol. In parallel, client generates a public/private key pair of the quantum-safe encryption algorithm, and send the public key to the server. The server picks a random string, $q$, encrypts it with the public key and send the ciphertext back to the client. The final secret is the output of KDF(c|q). This proposal defeats the harvest-then-decrypt attack with a minimum impact to the existing ntor protocol. An adversary needs to be able to break the quantum-safe encryption algorithm to learn q. On the other hand, if the quantum-safe encryption algorithm turns out to be not secure, the protocol is still as secure as ntor protocol. In other words, it will at least do no harm to the current security. In addition, this is a modular design that allows us to use any quantum-safe cryptographic primitives. As a proof of concept, we instantiated the protocol with NTRUEncrypt lattice-based crypto. We implemented the the protocol with NTRU parameters that gives 128 bits security. The code is available at https://github.com/NTRUOpenSourceProject/ntru-tor Please find the attachment for the request to change the feature. The proof of the protocol can be found at: https://eprint.iacr.org/2015/287.pdf Some known issue: 1. cell size. As far as we know, all quantum-safe encryption algorithms have large key and/or ciphertext size that exceeds the cell size ~500. So this protocol needs to transmit multiple cells, no matter which quantum-safe encryption algorithm we chose. This is addressed by "Proposal 249: Allow CREATE cells with >505 bytes of handshake data". 2. quantum-safe authentication: there is no quantum-safe authentication in this protocol. We believe that authentication can wait, as future (quantum) adversary cannot come back to present time and break authentication. Hence, we use ntor authentication to keep the proposal compact and simple. It will be a future work after this proposal. Thanks for your time, and happy holidays! Zhenfei Zhang Security Innovation.

9 26

Re: [tor-dev] Latest state of the guard algorithm proposal (prop259) (April 2016)
by George Kadianakis 29 Apr '16

29 Apr '16

Fan Jiang <fanjiang(a)thoughtworks.com> writes: > [ text/plain ] > On Fri, Apr 15, 2016 at 5:37 AM, George Kadianakis <desnacked(a)riseup.net> > wrote: > >> Fan Jiang <fanjiang(a)thoughtworks.com> writes: >> >> > [ text/plain ] >> > Thanks for the insights. >> > >> > >> >> >> It seems like the latest version of prop259 was posted a few weeks >> ago: >> >> >> >> >> https://lists.torproject.org/pipermail/tor-dev/2016-March/010625.html >> >> >> >> >> > <snip> >> >> > >> >> >> A few things: >> >> >> >> >> >> a) Are there still proposal design decisions that need to be taken >> and >> >> we >> >> >> are >> >> >> unclear on? I admit I'm a bit lost in the latest [tor-dev] >> thread, so >> >> >> maybe >> >> >> I can be of help somehow here? >> >> >> >> >> >> There are still some issues, like for_directory may leads to maintain >> >> two >> >> > sets of >> >> > sampled_set independently, which is not yet defined clearly in >> proposal. >> >> > >> >> >> >> Hm, how come this is happening? >> >> >> >> I would think that for_directory would now be just another filter (like >> the >> >> ipv6 one etc.) that can be applied on top of the sampled list. >> >> >> > The problem here is for_directory is a parameter of function call, that >> > means we can't do filter >> > before the call happens. Now the filter action only happens at START >> stage. >> > Maybe do a check before we return the selected guard (if not valid, then >> > continue picking new one) >> > can be a solution. >> > >> >> Hello, >> >> hm, that's an interesting problem... >> >> So we learn whether a circuit is for_directory when >> choose_random_entry_prop259() is called, but at that point the prop259 >> algorithm has already STARTed and its filtering parameters have been >> determined? >> >> So if some part of tor calls choose_random_entry_prop259() quickly twice, >> first >> with for_directory set, and the second time with for_directory unset, the >> guard >> algorithm will proceed in both cases with for_directory being set? Because >> the >> context has been set in the first call to choose_random_entry_prop259()? >> >> This seems like a problem to me, and I'm not sure how to solve it well... >> >> One way could be to use the 'cpath_build_state_t *state' in >> choose_random_entry_prop259() to be able to understand whether each call is >> about a different circuit or not. Then you could start a separate algorithm >> invocation (so new START) for each new circuit you see. >> >> But then I'm not sure how to do this without each separate algorithm call >> wrecking up the sampled_guards and used_guards lists... In the dev meeting >> in >> Valencia, we discussed with Ola and Reinaldo about using locking and >> blocking >> for this, but I'm not sure how much that would impact the performance... >> >> Do you guys have any plans here? >> >> We can have two pending_guard one for directory, one for any usage(which > will be picked by the NEXT algo, so they can be same node), > and they can be checked with directory flag before return. > Locking may not work because this algo should at least return sth before it > continues to another one, saying Dir and non-Dir are now in main loop, > Or if you have any ideas please let me know. > Hello Fan and team, I think I'm not a big fan of the pending_guard and pending_dir_guard concept. To me it seems like a quick hack that tries to address fundamental issues with our algorithm that appeared when we tried to adapt the proposal to the tor codebase. I think one of the main issues with the current algorithm structure is that _one run of the algorithm_ can be asked to _setup multiple circuits_, and each of those circuits has different requirements for guards. That is, since we do filtering on START based on the requirements of circuit #1, this means that any other circuits that appear before END is called, also have to adapt to the requirements of circuit #1. This is obvious in the code since we use guard_selection->for_directory throughout the whole algorithm run, even though for_directory was just the restriction of circuit #1. Specifically about the pending_guard trick, I feel that it interacts in unpredictable ways with other features of the algorithm. For example, consider how it interacts with the primary guards heuristic. It could be time for the algorithm to reenter the primary guards state and retry the top guards in the list, but because of the pending_guard thing we actually return the 15th guard to the circuit. IMO we should revisit the algorithm so that one run of the algorithm can accomodate multiple circuits by design and without the need for hacks. Here is an idea towards that direction: I think one very important change that we can do to simplify things is to remove the need to filter guards based on whether they are dirguards, fast, or stable. My suggestion here would be to *only* consider guards that are dirguards _and_ fast _and_ stable. This way, any circuit that appears will be happy with all the guards in our list and there is no need to do the pending_dir_guard trick. See [0] on why I think that's safe to do. This is easy to do in the current codebase. You just need to call entry_is_live() with need_uptime, need_capacity and for_directory all enabled (instead of flags being 0). If you do the above, your sampled guard set will be able to accomodate any circuit that comes its way and that should simplify logic considerably. Let me know if the above does not make sense. Here are some more comments: - So the above idea addresses a large part of the filtering logic that happens on START. The rest of the filtering logic has to do with ClientUsesIPv6, ReachableAddreses, etc. . I think it's fine to conduct that filtering on START as well. - I tried to run the branch as of bb3237d, but it segfaulted. Here is where it crashed: #1 0x000055555567eb25 in guards_update_state (next=0x5555559c3f40, next@entry=0x5555559c35e8, guards=guards@entry=0x5555559c4620, config_name=config_name@entry=0x55555570c47e "UsedGuard") at src/or/prop259.c:1137 1137 !strchr(e->chosen_by_version, ' ')) { Let me know if you need more info here. - There is a memleak on 'extended' in filter_set(). In general, I feel that logic in that function is a bit weird. The function is called filter_set() but it can actually end up adding guards to the list. Maybe it can be renamed? - What's up with the each_remaining_by_bandwidth() function name? --- [0]: I think that's OK to do and here is why: All Guards are Fast. About 95% of Guards are Stable (this will become 100% with #18624) About 80% of Guards are V2Dir/dirguards (this will become 100% with #12538) #12538 got merged in 0.2.8, so if prop259 gets merged in 0.2.9, by the time prop259 becomes active, almost all guards will be dirguards. So I think it's fine to only consider guards that are dirguards && fast && stable now, since by the time prop259 gets deployed that will be the case for almost 100% of guards.

2 7

QUIC TOR Debugging Question (no attach)
by Xiaofan Li 29 Apr '16

29 Apr '16

Hi Tim and everyone on tor-dev, Our QUIC + TOR project has almost been fully implemented. We are debugging the last few bits of bugs. Update: 1. *We've now able to build many complete circuits with QUIC as its underlying protocol. * 2. We have not debugged the actual communication part yet. We are aware of certain failure cases for QUIC (e.g. line 15642 of the log is being debugged right now). So we cannot send actually client data yet. 3. The current state uses QUIC for OR connections only. Thus a dual-path is implemented as suggested in my last email thread. 4. TLS is completely bypassed and important state (that is set up in tls_handshake functions) is preserved and refactored out. e.g. conn->/chan->state purpose, etc. 5. Some tinkering and re-designing of QUIC itself is also underway. The fact that QUIC is a transport protocol on application layer makes it painful to interact with the event and timer systems of TOR. We are trying to improve this aspect now. *The debugging log I was attaching was too big for the tor-dev list. So if you are interested to take a look at the file, let me know. Your help is greatly appreciated! * Some particularly concerning things in the log: 1. *circuit_get_by_circid_channel_impl(): found nothing for circ_id 14801, channel ID 2 (0x7f758bb6b740)* Then it just attaches this circ onto this channel.. Is this normal? 2. *Line 4901 circuit_receive_relay_cell(): Passing on unrecognized cell.* It happens a lot. Is this normal? 3. This sequence happened a lot around 7500. *relay_send_command_from_edge_(): delivering 10 cell forward. circuit_package_relay_cell(): crypting a layer of the relay cell. circuit_package_relay_cell(): crypting a layer of the relay cell. circuit_package_relay_cell(): crypting a layer of the relay cell.* It seems like its decrypting and forwarding cells along. Is it normal for TOR (with TCP) to do this in a burst? Because I'm seeing about ~1s of repeated calls. *Some more general questions:* 1. Internal Circuits: any docs? What is it used for? Measuring bandwidth? How many internal circuits are required by the system? 2. *circuit wide ID format.* We had a bug regarding this last week. The check in process_create_cell always fails because line 281-295 in *command.c* always failed (the check for CIRC_ID_TYPE and id_is_high). Currently we commented out this check. What does it affect? And could we do this? 3. From a high level, when a client sends data using a circuit, what is its code path? Which special (as in, specific to client-initiated communication) functions are called? Any other comment on the log is greatly appreciated, since everyone here is probably more familiar than me with what a normal bootstrapping process would look like. Thank you!

2 4

Tor crash debug
by Nurmi, Juha 29 Apr '16

29 Apr '16

Hi, I have been running Tor on tor2web mode[1] and now it has started to crash. See error on /log http://nzxj65x32vh2fkhk.onion/pwnzwpknl To understand the bug I re-installed Tor in Tor2web mode for debbuing: make clean && CFLAGS="-ggdb3 -O0" LDFLAGS="-ggdb3" ./configure --disab le-asciidoc --enable-tor2web-mode && make && make install And running it gdb tor (gdb) run Program received signal SIGSEGV, Segmentation fault. 0x00005555555c02d6 in rend_client_get_random_intro_impl ( entry=0x5555555bf1bf <rend_client_fetch_v2_desc+114>, strict=0, warnings=0) at src/or/rendclient.c:1353 1353 smartlist_add_all(usable_nodes, entry->parsed->intro_nodes); Any ideas what is the problem? Is there anything more I could do to debug this? [1] https://github.com/globaleaks/Tor2web/wiki/Installation-Guide Best, Juha

3 3

Onioncat and Prop224
by grarpamp 27 Apr '16

27 Apr '16

On 4/25/16, Tim Wilson-Brown - teor <teor2345(a)gmail.com> wrote: > >> On 22 Apr 2016, at 17:03, grarpamp <grarpamp(a)gmail.com> wrote: >> >> FYI: The onioncat folks are interested in collaborating >> with tor folks regarding prop224. >> >> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.t… > > I'm interested in what kind of collaboration onioncat would like to do on > prop224, next-generation hidden services. > It would be great to work this out in the next few weeks, as we're coding > parts of the proposal right now. Yep :) And I know Bernhard was hoping to get in touch with Roger on this before long. Basically, prop224 HS being wider than 80 bits will break onioncat's current HS onion <---> IPv6 addressing mechanism. They're looking at various backward compatibility options, as well as possibly making side use of the HSDir DHT, or even integrating more directly with the tor client. Onioncat v1 is here: https://www.onioncat.org/ https://www.cypherpunk.at/onioncat_trac/ https://www.cypherpunk.at/ocat/download/Docs/ list: onioncat(a)lists.blackmesa.at # 25c3: OnionCat - A Tor-based Anonymous VPN - Fischer / Haslinger https://www.youtube.com/watch?v=rx4rS1gvp7Y # Other Media https://twitter.com/search?q=onioncat https://www.youtube.com/watch?v=RFHD6rKX3LI https://elbinario.net/2014/12/02/onioncat-es-onion/ https://thehackerway.com/2011/11/14/preservando-el-anonimato-y-extendiendo-… # test a5ccbdkubbr2jlcp.onion:8060 ping6 -c 10 fd87:d87e:eb43:0744:208d:5408:63a4:ac4f 10 packets transmitted, 10 packets received, 0.0% packet loss round-trip min/avg/max/std-dev = nnn/nnn/1nnn/1nn ms Onioncat v2 is beginning here: # OnionCat and Tor's new Cryptosystem - Fischer https://www.youtube.com/watch?v=Zj4hSx6cW80 https://itsecx.fhstp.ac.at/wp-content/uploads/2014/11/FischerOnionCat.pdf I wanted to link you out to the recent onioncat list threads on v2, but that list and its archive is down right now pending them getting it back online. I could forward the posts. Other interested people may be: # David Stainton - OnionVPN - ipv6 to onion service VPN adapter https://github.com/david415/onionvpn # Stefan Grundmann - erl_ocat - erlang onioncat implementation https://github.com/sg2342/erl_ocat # Ferdinand Haselbacher - onioncat - debian port contributed https://www.cypherpunk.at/onioncat_trac/ # intrigeri - onioncat - debian port, etc https://packages.debian.org/sid/onioncat > But the tor-onions mailing list is to discuss the technical details running > onion services. Readers of tor-onions / newbies may have been unfamiliar with onioncat. It's a way to get non-TCP between TorHS onions, thus in the thread "Hidden datagram service". I think there are a nontrivial number of users interested in, and using, non-strictly-TCP transport over an IPv6 tunnel interface. For example, look at users of CJDNS... https://www.youtube.com/results?search_query=CJDNS https://www.youtube.com/results?search_query=hyperboria For which we should try to continue a way, in v2, to do that over anonymous overlay network Tor / I2P. > Can we discuss onioncat, tor, and the development of prop224 on tor-dev > mailing list? Sounds good, especially with the onioncat list being down right now. Onioncat list had reliability issues in the past, maybe torproject would like to host it and import its ezmlm and mailman archives?

1 0

Orfox: Tor Browser for Android - GSoC 2016
by Amogh Pradeep 26 Apr '16

26 Apr '16

Hey guys, I’m amoghbl1, a 3rd year undergraduate student at International Institute of Information Technology, Hyderabad. I have been selected to work on Orfox this summer as part of Google Summer of Code. Here is my proposal if anyone wants to take a look at it: http://people.torproject.org/~amoghbl1/GSoC_2016.pdf <http://people.torproject.org/~amoghbl1/GSoC_2016.pdf> . I have tried to contribute to tor project as much as I can since 2013. I started working on Orbot late 2013 and did GSoC with tor in 2014. Since then, I have tried to involve myself with this community as much as I can. Trying to balance college work and my open source work has been difficult, but I’ve tried my best and have dedicated the past two summers to tor. In 2014, it was GSoC and in 2015, I went on to become an intern at The Guardian Project. This summer, I get to contribute again and hope to continue doing so after the summer as well. I will also be pursuing research this summer, as a visiting scholar at Katholieke Universiteit Leuven. But the best part is, I am going to do research browser fingerprinting risks for mobile browsers and Orfox. So I guess I get to enjoy the best of both worlds of research and development! Please do let me know if you have any suggestions, I’m always available on email and IRC. amoghbl1 on OFTC as well as Freenode. Best, Amogh Pradeep amoghbl1(a)gmail.com <mailto:amoghbl1@gmail.com>

1 0

Stress testing guard nodes
by Abhishek Singh 26 Apr '16

26 Apr '16

Hi, I am trying to identify bottlenecks at an entry guard when it is used to create a large number of circuits. To identify this I started a set of clients which use a single entry-guard to create 5K-10K circuits in total. With this scale clients observe timeouts (waiting for CREATED cell) while constructing circuits and they consider the entry guard to be down. I control the entry-guard chosen in this experiment and no other client should be using this relay node as a entry guard as it does not have GUARD flag in consensus. Lack of bandwidth at the entry guard is not the cause for timing-out for circuits. It consumed 80-90 KBps while the entry guard's RelayBandwidthRate is set to 400 KBps. Also, CPU at the entry-guard is not bottleneck as it was always less than 10% during the course of experiment. Can anyone provide me pointers to why these circuits timeout? And, what would be an effective way to verify that this indeed is the bottleneck? I tried profiling the entry-guard with callgrind but this is extremely slow. In the meanwhile I will create a static tor instance so that gprof produces some meaningful results. Motivation for this work is to enable a client to predict how many circuits it can create without degrading performance of its entry-guards. If a circuit is not created within a timeout period, then the client perceives the entry guard to be down and it starts using another guard node. If the client keeps on creating excessive circuits, then it is more likely to end-up using a malicious (and resourceful) entry guard. The prediction model would help the client to stay anonymous as it would refrain from unnecessarily switching guard nodes. Thanks, Abhishek

2 1