- tor-dev - lists.torproject.org

Propsal 263 Quantum-safe Hybrid handshake for Tor, updated feature request v1.2
by Zhenfei Zhang 08 Feb '16

08 Feb '16

Hello list, We had a very constructive discussion on this proposal last Thursday. I have updated the feature request based on the feedback from the discussion. We also like to thank Roger for grammar fixes on the proposal. The diff file is available at: https://github.com/zhenfeizhang/ntru-tor/commit/dc48c2065d1772c5497cd6ad900… Major tech updates are: 1. Use SHA3 and SHAKE instead of HMAC_SHA3 2. In previous proposal, when server sends back the message, it sends a ciphertext C = ENCRYPT( P | B, QSPK), and its one-time ECC public key Y = e^y; where P is the secret that server chose, B is servers long term public key. In this new version, we also include servers short term public key in the plaintext, i.e., C = ENCRYPT( P | B | Y, QSPK) and Y is no longer send to the client separately. The client will need to decrypt C first and retrieve Y from the message. Y is not revealed to any one other than the client. This is proposed by Nick. It was also suggested to us by Aniket Kate. We thank Nick and Aniket for the suggestion. This modification will save 32 bytes of traffic as Y is no longer transmitted. Also since Y is now encrypted it will be a little harder for the attacker to attack the 25519 keys. 3. Choosing algorithms and parameters for the protocol. We have identified NTRUEncrypt and R-LWE as two candidates for this protocol. We have agreed to use NTRUEncrypt for now, in the meantime, keep the option open for "newesthope" version of R-LWE type key exchange when it becomes available. Also, for NTRUEncrypt we will be using parameters sets with SHA3, to align with Tor specs. I have modified the feature request to reflect this change. Also in the discussion we were talking about the possibility of using non-product form polynomial version of NTRUEncrypt, as this version will become patent free by Aug 2017, while the patent for product form will last for another 4 years. The main concern is that Debian will not allow patented software in the package. However, through our discussion, it turns out that we may be able to include this proposal in the next one of two release of Tor. From this point of view, both patent (basic NTRU patent, till 2017 and product form patent, till 2021) are going to be an issue if Debian does not agree with SI's patent statement. So does it make sense to keep the product form polynomials as they enables roughly 3 times faster operations on both client side and server side? Thanks for your time, and please let us know if you have any further comments/suggestions. Best regards, Zhenfei

2 1

Re: [tor-dev] Detailed algorithm
by George Kadianakis 08 Feb '16

08 Feb '16

> Hey, > > So - thinking through your comments and thoughts, I realized that the > better way to proceed was to describe the algorithm, and then put it > into a proposal format. The following is updated with most of your > comments and should be a bit clearer. I decided to remove #241 again, > since it's unclear how it actually fits together with #259. The idea > is that the algo is divided into three pieces. If failure is reported > from the algorithm, the caller can wait for a while or just restart it > from scratch immediately: > I feel that this algorithm is a step in the right direction! It's interface logic is quite similar to how Tor picks its guards, and it's more specific than the previous proposals. It's a good first step so I'll CC tor-dev so that Nick, Isis and other people can take a look if they want. After we pin this down, we also need to collect all its security properties in one place. For example, we should state clearly what security properties the thresholds GUARDS_TRY_THRESHOLD_TIME and GUARDS_FAILOVER_THRESHOLD provide. I inline various questions below. I can take a deeper look tomorrow as well. > - Start of algorithm > - Ensure USED_GUARDS is populated (from state file etc) > - Create a list of PRIMARY_GUARDS that contain N_PRIMARY_GUARDS that are not bad by: > - Taking the next entry from USED_GUARDS > - If USED_GUARDS is empty: > - randomly select an entry from UTOPIC_GUARDS, weighted by bandwidth Hmm. PRIMARY_GUARDS stays like this for ever? It probably needs to be updated when a primary guard get removed from the consensus (become bad), and put the next entry of USED_GUARDS in its place. Maybe we need another event (and algorithm) for "receive new consensus"? Or is this considered out of scope? > - Set TRIED_GUARDS to be an empty set Hm. What is the point of TRIED_GUARDS? It's like a list of guards that we found unreachable at some point in time. It's never cleaned, so it will eventually accumulate many nodes. IIUC, we only use that list to enforce our thresholds by looking at timestamps. Can we do without this list, just by checking the timestamps of unreachable USED_GUARDS? Or the logic will be much more complicated? > - Set TRIED_DYSTOPIC_GUARDS to be an empty set > - Set state = STATE_PRIMARY_GUARDS > > - Each iteration of algorithm > - If it was at least 3 minutes since we tried the primary guards and we are not in STATE_PRIMARY_GUARDS: > - save previous state > - set state = STATE_PRIMARY_GUARDS > > - STATE_PRIMARY_GUARDS: > - return each entry in PRIMARY_GUARDS in turn > - mark each entry as "unreachable" if algorithm doesn't terminate What is the "algorithm" here? Is it the guard selection algorithm, or the circuit construction algorithm? I guess the latter? If it's indeed the circuit construction algorithm, then the steps here are not asynchronous anymore, which diverges from how Tor networking is designed. Maybe this could be fixed by introducing some new states for when we are waiting for a circuit to connect and we are now learning whether it was succesful or not. Basically what entry_guard_register_connect_status() does in Tor right now. For example we could have STATE_WAITING_FOR_PRIMARY_GUARD_CIRCUIT for when we are waiting for a primary guard circuit to connect. If it fails, then we need to mark the entry as unreachable. Maybe we also need STATE_WAITING_FOR_UTOPIC_GUARD_CIRCUIT etc. > - restore previous state (or STATE_TRY_UTOPIC if no previous) > > > - STATE_TRY_UTOPIC: > - for each entry in TRIED_GUARDS that was marked as unreachable more than 20 minutes ago > - add to the front of remaining UTOPIC_GUARDS Isn't it already in UTOPIC_GUARDS? I don't see us ever removing stuff from UTOPIC_GUARDS. BTW, what is this step supposed to do? Setup previously TRIED_GUARDS to be retried? > - return each remaining entry from USED_GUARDS in turn > - for each entry, if algorithm doesn't terminate > - mark entry as "unreachable" > - add entry to TRIED_GUARDS Add it there even if it it's already there (TRIED_GUARDS is never cleaned)? Or maybe update a timestamp if it's already there? How to specify this nicely? > - if the number of entries in TRIED_GUARDS that were tried within GUARDS_TRY_THRESHOLD_TIME > is larger than GUARDS_TRY_THRESHOLD, return failure from the algorithm > - if the number of entries in TRIED_GUARDS is larger than a GUARDS_FAILOVER_THRESHOLD > proportion of UTOPIC_GUARDS, set state = STATE_TRY_DYSTOPIC > - return each remaining entry from UTOPIC_GUARDS randomly selected, weighted by bandwidth > - for each entry, if algorithm doesn't terminate > - mark entry as "unreachable" > - add entry to TRIED_GUARDS > - if the number of entries in TRIED_GUARDS that were tried within GUARDS_TRY_THRESHOLD_TIME > is larger than GUARDS_TRY_THRESHOLD, return failure from the algorithm > - if the number of entries in TRIED_GUARDS is larger than a GUARDS_FAILOVER_THRESHOLD > proportion of UTOPIC_GUARDS, set state = STATE_TRY_DYSTOPIC > TRIED_GUARDS is never cleaned, so this will be almost always true after a while. > - STATE_TRY_DYSTOPIC: > - for each entry in TRIED_DYSTOPIC_GUARDS that was marked as unreachable more than 20 minutes ago > - add to the front of remaining UTOPIC_GUARDS Does it matter if we add it to the front or the back of UTOPIC_GUARDS? >From what I understand, we always sample from UTOPIC_GUARDS based on relay bandwidth so the list order should not matter, right? [This comment and also the comments below also apply for the STATE_TRY_UTOPIC case above] > - return each remaining DYSTOPIC entry from USED_GUARDS in turn Do we even try previously-found unreachable guards here? > - for each entry, if algorithm doesn't terminate > - mark entry as "unreachable" > - add entry to TRIED_DYSTOPIC_GUARDS Order matters here right? We probably want FIFO. > - if the number of entries in TRIED_GUARDS+TRIED_DYSTOPIC_GUARDS that were tried within GUARDS_TRY_THRESHOLD_TIME > is larger than GUARDS_TRY_THRESHOLD, return failure from the algorithm > - if the number of entries in TRIED_DYSTOPIC_GUARDS is larger than a GUARDS_FAILOVER_THRESHOLD > proportion of DYSTOPIC_GUARDS: > - mark all guards in PRIMARY_GUARDS, TRIED_GUARDS and TRIED_DYSTOPIC_GUARDS as not "unreachable" > - return failure from the algorithm > - return each remaining entry from DYSTOPIC_GUARDS randomly selected, weighted by bandwidth > - for each entry, if algorithm doesn't terminate > - mark entry as "unreachable" > - add entry to TRIED_DYSTOPIC_GUARDS > - if the number of entries in TRIED_GUARDS+TRIED_DYSTOPIC_GUARDS that were tried within GUARDS_TRY_THRESHOLD_TIME > is larger than GUARDS_TRY_THRESHOLD, return failure from the algorithm > - if the number of entries in TRIED_DYSTOPIC_GUARDS is larger than a GUARDS_FAILOVER_THRESHOLD > proportion of DYSTOPIC_GUARDS: > - mark all guards in PRIMARY_GUARDS, TRIED_GUARDS and TRIED_DYSTOPIC_GUARDS as not "unreachable" Hm, not sure what this is supposed to do. Is it trying to setup the algorithm to retry all guards from the beginning? Shouldn't we edit USED_+GUARDS in that case? > - return failure from the algorithm > Instead of failing in this case, shouldn't we just retry from the top without adding any new guards if we hit these thresholds? How do we do this? Or is this logic considered out of scope? :x > - End of algorithm > - If circuit is set up correctly, let algorithm know > - Algorithm marks the guard chosen as used and makes sure it is in USED_GUARDS > - Otherwise do another run of the algorithm > When does this "End of algorithm" happen?

1 0

Configuration of tor relay using setup files (use of API via Tor Expert Bundle)
by Nathan Bliss 07 Feb '16

07 Feb '16

Hi, Is there a way to configure a bridge in tor (e.g. meek) via the config files from the command line without having to use the GUI in the Tor browser? I've been searching for documentation on this, so if I've missed it I would be grateful for a pointer to where this is in the docs... I found something about the torrc but this was an option for configuring a tor server node as a bridge whereas I want to configure the bridge as a client (in client mode). I need to do this in order to have automation scripts working with search engines such as google. Google always seems to be able to detect http connection via a script or via the tor interface running in standard mode. Only a client connection via google-meek bridge seems to work and I'm looking for a way to do this via the tor stem API or via the config files. If this feature isn't currently exposed as an API hook, I'd be happy to contribute this feature to the source code if someone can give me a few pointers as I'm new to the project and haven't yet seen any of the source [&#X1f60a] Many thanks, Nathan

2 1

Re: [tor-dev] Hashring understanding
by George Kadianakis 07 Feb '16

07 Feb '16

Ola Bini <obini(a)thoughtworks.com> writes: > Hi, > >> I think it's fine to use randomness to generate it for now; that's what tor >> also currently does [0]. > Cool - we have a local clone of the specs and updating it with this understanding. > Great! For better or worse I think making design decisions (or at least simulating them) as well as improving and finalizing the spec is a big part of this task :) >> The real lifetime of guards is currently a random value between 2 to 3 months >> (see chosen_on_date) This is regardless of whether the guard is your primary >> guard or not. We might increase the lifetime in the future, but probably the >> precise value should not matter too much since it's a constant >> change. > Does this mean the choice of guard is saved in the state file or > config file? Indeed. It is saved in the state file. Check the end of: https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html also see here for another explanation of how parts of it work: https://lists.torproject.org/pipermail/tor-dev/2014-June/007042.html > Should the PRIMARY_GUARDS chosen by #259 here be saved as well? Hmm. Not sure how this will work exactly in practice. The way I imagine it, is that the first N_PRIMARY_GUARDS active guards on your guard list are considered to be your primary guards. It's more of a label, than a static set. That's because the set of primary guards changes over time, as nodes go inactive. Like prop259 says, "by 'active' we mean that we only consider guards that are present in the latest consensus as primary". > I suspect that might not work very well because of the difference between > dystopic and utopic networks, and when people move around between > networks. Or maybe we should have two sets, UTOPIC and DYSTOPIC > PRIMARY_GUARDS that are more long lived? Hmm... Not sure how this would work if utopic and dystopic guard lists are separated. That is if there should be both dystopic primary guards _and_ entropic primary guards. I'd personally prefer the approach where we don't have such strictly separated guard lists. I tried to explain parts of it in the top of this email: https://lists.torproject.org/pipermail/tor-dev/2016-February/010355.html but it probably requires more design work. The way I'm thinking of it, we have a main guardlist GUARDS, where we put every guard we have sampled and connected or planning to connect to. We would sample both normal and 80/443 guards for this guardlist. This guardlist should work for most clients (except from 80/443 firewalled clients). To handle these 80/443 firewalled clients, if we try more than GUARDLIST_FAILOVER_THRESHOLD nodes from GUARDS and we can't connect, then we consider it to be a firewall issue, and go into "dystopic firewall mode". During this mode we only sample dystopic guards (potentially from a separate DYSTOPIC_GUARDS guardlist). If we try more than GUARDLIST_FAILOVER_THRESHOLD of guards from the dystopic guardlist, then we complain about network issues. (There are various optimizations and heuristics that can be applied to the above system, but let's not get to them now.) [The reason I don't like having separate disjoint utopic and dystopic guardlists and first trying the former and then the latter, is because it means that normal people will use the utopic guards, and the dystopic guards will only be used by people that have 80/443 firewalled. We don't really know how big these user sets are right now so it's hard to make load-balancing assumptions, and from a security PoV we should probably not isolate those user sets if we can help it.] Bleh sorry for the mess... It's been a while since I've thought of this stuff.

2 3

Re: [tor-dev] Guards selection - current algorithm simulation
by George Kadianakis 05 Feb '16

05 Feb '16

Iván Pazmiño <ipazmino(a)thoughtworks.com> writes: > Hello, thanks for your reply. > > On 02/04/2016 04:28 PM, George Kadianakis wrote: >> We don't actually and it's a pity because it would have been very useful for >> this particular case indeed. > We will write one then. > Exciting! >> >> However, the entry guard code in Tor is not particularly clean or well >> abstracted. So finding the underlying algorithm will not be a trivial task. >> That's also another reason we are trying to move to a more formalized >> algorithm, so that it's more easily studied. > We've started looking at the code and so far we believe the relevant > scenarios would be those when you invoke choose_random_entry_impl with a > NULL state. Would that be correct? > I _think_ that also the non-NULL state scenario is relevant. choose_random_entry_impl() is called with an initialized state in onion_extend_cpath(). That's the codepath when "we are building a circuit and we need an entry guard for it". choose_random_entry_impl() is called with a NULL state in add_an_entry_guard(). That's the codepath for "shit we are out of entry guards. We need a new one." I think both of these codepaths are relevant. Maybe to make sure, add some logging calls in choose_random_entry_impl() and start up your Tor, to see if it's called with a NULL state or not. > Cheers, > Iván

1 0

Re: [tor-dev] Hashring understanding
by George Kadianakis 04 Feb '16

04 Feb '16

Ola Bini <obini(a)thoughtworks.com> writes: > Hi, > > Sorry for the string of emails! > > Hopefully a simple question: > The current proposal contains logic for keeping track of network > up/down and setting timeouts for exponential backoff to test the > network again. But if I understand correctly, this proposal is > basically about replacing the algorithm used for > choose_good_entry_server() - correct? So it seems like keeping track > of network status doesn't really belong inside this algorithm at > all. Wouldn't it make sense to return a specific failure to the caller > and let the caller be in charge of when to retry? > Hmm. It's quite hard (if not impossible) for a user-land application like Tor to actually keep track of whether the network is up or down in a multiplatform, secure and scalable manner (e.g. without using the dirauths as an oracle). So instead all we do is connect to Tor nodes and check whether we could reach them or not. I think currently if a relay fails to answer a CREATE cell, we treat the relay as unreachable and we mark it as such in our guardlist (see entry_guard_register_connect_status()). This logic is considered suboptimal and it sometimes ends up marking good relays as unreachable. The retry logic in prop259 tries to compensate for this, by eventually retrying nodes that might have been marked as offline by a shaky network. I agree it would be nice to decouple the above behavior from the guard picking behavior. However, the two behaviors are certainly linked with each other, since the only nodes that a Tor client connects to are its guard nodes. I'm not sure how separating these two behaviors would look like, but if you guys think it would simplify things I'd definitely be interested in hearing about it :) WRT current code, if you see choose_random_entry_impl() (which is called by choose_good_entry_server()) you will notice that the status of relays is very central to this function since populate_live_entry_guards() will remove any guards that are inactive or previously found unreachable from the guardlist. choose_random_entry_impl() does not contain logic about the network itself being up and down, because currently Tor does not have such logic. Instead, Tor will endlessly keep on cycling through guards till the network comes up. Hopefully I answered the right question here. BTW, if you guys want we can have another meeting next week Tuesday same time iff that will be helpful to you. cheers!

1 0

Re: [tor-dev] Guards selection - current algorithm simulation
by George Kadianakis 04 Feb '16

04 Feb '16

Iván Pazmiño <ipazmino(a)thoughtworks.com> writes: > Hey guys, > > Just wondering if by any chance you have a simulator for the current > algorithm to select guards. It would be very useful to compare against > new algorithm's numbers. > > Thanks, Hello, We don't actually and it's a pity because it would have been very useful for this particular case indeed. However, the entry guard code in Tor is not particularly clean or well abstracted. So finding the underlying algorithm will not be a trivial task. That's also another reason we are trying to move to a more formalized algorithm, so that it's more easily studied.

1 0

Re: [tor-dev] Hashring understanding
by George Kadianakis 04 Feb '16

04 Feb '16

Ola Bini <obini(a)thoughtworks.com> writes: > Hi, > > Thanks for the confirmation of our understanding! Very helpful. > > If I understand things correctly, we are supposed to take > GUARDLIST_FAILOVER_THRESHOLD guards from the list of all guards and > generate the GUARDLIST from that. Is that process supposed to be > deterministic for a specific client on a specific network, or is it > fine to use randomness to generate it? > Hello, I think it's fine to use randomness to generate it for now; that's what tor also currently does [0]. I think coming up with the right way to do deterministic sampling based on specific networks can be the subject of a separate proposal :). I imagine that there will be engineering and security issues that will complicate any easy approaches. So you can ignore this part of the problem for now, and just use fresh local randomness everytime you sample a guard :] > And how long lived are the PRIMARY_GUARDS supposed to be? The real lifetime of guards is currently a random value between 2 to 3 months (see chosen_on_date) This is regardless of whether the guard is your primary guard or not. We might increase the lifetime in the future, but probably the precise value should not matter too much since it's a constant change. [0]: see choose_good_entry_server() -> router_choose_random_node() -> smartlist_choose_node_by_bandwidth_weights()

1 0

Re: [tor-dev] Hashring understanding
by George Kadianakis 04 Feb '16

04 Feb '16

Ola Bini <obini(a)thoughtworks.com> writes: > Hi, > > Sorry for this - had some questions about the hashring component of > #259 that I haven't been able to figure out myself. I'm sure it's just > me being unused to the Tor code base and how you write your proposals, > but it would be super helpful if I can get a quick answer to a few > questions. > > First, my simplified understanding of the data structures is this: > GUARDS are all the guards in the consensus > > UTOPIC_GUARDS is all utopic guards from GUARDS > DYSTOPIC_GUARDS is all dystopic guards from GUARDS > > UTOPIC_GUARDLIST is a subset of UTOPIC_GUARDS > DYSTOPIC_GUARDLIST is a subset of DYSTOPIC_GUARDS > > We will only ever choose guards to use from UTOPIC/DYSTOPIC_GUARDLIST > > The idea of the hashring is to be a structure to make it possible for us to > go from UTOPIC/DYSTOPIC_GUARDS to UTOPIC/DYSTOPIC_GUARDLIST. > The reason we want to avoid shifting is because we want the hashring to be a > long lived data structure that can be cheaply updated over p> several consensuses. > > Here are my questions: > - Is the above understanding correct? Yes, that's also my understanding. I think what prop259 tries to do with that hashring construction is to provide a deterministic way to sample guards, with minimum shifting as time passes. The aim here is to make it harder to track and fingerprint clients based on their guard lists. The idea is that when you are in WiFi "home" you always have one set of guards, and when you move to the WiFi "cafe" you have a different set of guards. See #10969 for some background and check http://meetbot.debian.net/tor-dev/2016/tor-dev.2016-01-19-16.03.log.html starting from 16:21:58 for some recent discussion. Personally, I think that the hashring is kind of a red herring in the sense that it makes prop259 more complex than it needs to be, and it also tries to tackle a problem that we don't really know how to solve. I mean even if we have the hashring construction, how do we use it? Do we just blend in the MAC of the network gateway when we sample guards? What happens if an evil gateway changes its MAC constantly, till we sample the guards it wants? I think solving the guard fingerprinting issue should be the subject of a separate proposal. Isis suggested this during the meeting but I was too dump at that point. Until we have a proper solution here I'd suggest we stick to the KISS thing, which probably is to sample guards from a simple list weighted by their bandwidth like Tor is currently doing (see node_sl_choose_by_bandwidth()). Of course, if you guys are interested in this and want to simulate the hashring idea (or any othe similar idea) that's fine as well. That's the good part of a simulation; that we don't need to commit to any particular construction. > - At what point do we add/update/change guards in UTOPIC/DYSTOPIC_GUARDLIST? I think prop259 suggests that we populate the guardlists the first time Tor attempts to connect to a network. This is different to how Tor currently does it, where it starts with a minimal guardlist (one guard), and adds new guards to it on demand (when the first guard fails). Both approaches have their merits. I'm not sure which one is better. We add more guards to guardlists if all the previous guards don't work anymore. This can be seen in step 4 of §2. We also need to mark (update) guards as unreachable when they get removed from the consensus, or when we fail to connect to them. Indeed the proposal should be updated to better specify when these actions happen and how they work. > - Since each key in the hashring structure depends acutely on bw_weight_total > and the BW of the guard, how will it be possible to update it > efficiently? My assumption is that the bw_weight_total will change on every > consensus, and at that point all the old keys are invalid?

1 0

(no subject)
by Christian Sturm 04 Feb '16

04 Feb '16

Hello, a while ago I set up a BSD buildbot for tor[1]. It's actually not just for BSDs, but also for other systems, such as Solaris. I wanted to make it easier to notice when something breaks on non-popular systems, not actively used by the developers. There also is reporting through an IRC bot and I wanted to ask if it would be interesting to have it report there. Currently it just lurks in there and lacks the permission to report build failures. So it would be great if the user 'bsdbuildbot' could get those permissions. I was wondering whether this is something that developers are interested in and if so what kind of reporting they'd like to have. Currently (if it would be allowed to) it would report individual build failures and success, but of course if that's too noisy could also change to just notify when this changes. Thanks to weasel there also is a FreeBSD builder for Jenkins. However that's only FreeBSD for now. The buildbot already has some other operating systems as build slaves and it's rather simple to set it up. Chris [1] http://buildbot.pixelminers.net/

1 1