April 2020 - tor-dev - lists.torproject.org

Relay Truncated Cell Example
by Eli Vakrat 28 Apr '20

28 Apr '20

Hello again everyone! For anyone who doesn't know\remember, my name is Eli, I'm a high school student from Israel and I'm currently trying to implement a TOR Client in Python. Currently, my project is configured so that my python client (OP) has its guard node set as my local machine (which is running a downloaded version of TOR). I do this for debugging purposes so that if I send a malformed cell as the implemented client, I can read the debug log that the OR generates and see what I did wrong. Last time I sent a question to the dev-list I was stuck trying to get my CREATE cells to work, and Nick Mathewson immediately answered my question and helped me a lot! Thanks Nick! I've made pretty good progress since then, and as of writing this, my implemented OP can successfully send a CREATE cell and even an EXTEND cell to my guard node. However, I am running into a problem while trying to extend my circuit to the third node (my exit node in this case). After sending a RELAY_EXTEND cell to my middle node (which is encrypted twice with my middle node and then guard node forward key using AES128 in CTR mode), the Response I get back is a relay cell with the correct Circuit Id and command (the command I get is the RELAY command which is represented as 3), BUT the payload of the response cell is very weird. I am unable to 'recognize' it (as specified in section 6.1 of the tor-spec). and furthermore, it does not seem to be any type of cell, it just seems like a bunch of nonsense. Seeing this I initially thought that the response cell I kept getting was a RELAY_EXTENDED cell that I couldn't 'recognize' due to an error while decrypting the cell payload. But then I looked at the debug log of my guard node (remember that my guard node is on my local machine) and it said that it had received a DESTROY Cell back from the middle node and was passing on a RELAY_TRUNCATED cell to me: *Apr 26 16:11:03.014 [debug] command_process_destroy_cell: Received for circID 2297363203.* <------this is the circuit ID between my gaurd node and the middle node *Apr 26 16:11:03.014 [debug] command_process_destroy_cell: Delivering 'truncated' back.Apr 26 16:11:03.014 [debug] relay_send_command_from_edge_: delivering 9 cell backward.* To my understanding what this log means is that some part of the EXTEND cell I sent to the middle node was wrong or malformed and because of this when the middle node tried to extend the circuit, an error occurred, and the circuit needed to be torn down. This is very weird because when I send an EXTEND cell that is meant for my guard node (meaning I want to extend the circuit from one hop to two hops) everything works fine, and I can even successfully derive the shared key material for the middle node. So I have several questions regarding this: 1. First of all, I didn't quite understand the exact format of a RELAY_TRUNCATED cell. Does it contain a relay cell command + recognized+field +digest and so on? or is it just a single octet that immediately follows the cell command field? If some could show me an example of the cell, it would be much appreciated... 2. What are some common errors that would make an OR drop a RELAY EXTEND cell? I thought maybe it was a problem with my TAP handshake data, but after extensive checking that doesn't seem to be the case. 3. If someone could describe the exact steps of extending a circuit to a third node, it would greatly help me to make sure that I didn't miss a step or do something wrong. Thanks in advance for any answers, examples, or comments! I am having a lot of fun doing this project so far and I hope to hear back from anyone who has an answer :) Regards, Eli

2 1

Walking onions status update: week 8
by Nick Mathewson 27 Apr '20

27 Apr '20

Walking Onions: week 8 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and Merkle Tree trickery. https://lists.torproject.org/pipermail/tor-dev/2020-March/014178.html Week 2: Specifying details of SNIP and ENDIVE formats, in CDDL. https://lists.torproject.org/pipermail/tor-dev/2020-March/014181.html Week 3: Expanding ENDIVEs into SNIPs. https://lists.torproject.org/pipermail/tor-dev/2020-March/014194.html Week 4: Voting (part 1) and extending circuits. https://lists.torproject.org/pipermail/tor-dev/2020-March/014207.html Week 5: Voting (part 2) https://lists.torproject.org/pipermail/tor-dev/2020-April/014218.html Week 6: Editing, voting rules, and client behavior (part 1) https://lists.torproject.org/pipermail/tor-dev/2020-April/014222.html Week 7: Exit policies: How do they work? https://lists.torproject.org/pipermail/tor-dev/2020-April/014232.html == Onion services: surprisingly easy! (but not?) This week I started with a look at onion services and how to make them work with Walking Onions [ONIONSPEC]. Most of my initial thought had gone into the problem of finding and using HSDirs, and so specifying this part went smoothly. I already havd a link specifier for asking for a span of several entries in an ENDIVE, and I already had a notion of truncating index values based on a network parameter. The harder part came when I wanted to talk about how to specify introduction points and rendezvous points by their SNIPs. The hard part here was managing the migration path. To avoid fingerprinting, when we make changes to the onion service protocol of this kind, we need to give a lot of onion services and clients the opportunity to start supporting the new protocol all at once, and then to stop supporting the old one all at once. This requires more network parameters, somewhat carefully specified. I'm hoping we can turn this into a more general pattern. And the most irritating part is when I ran into the issue of supporting HSv2 handshakes. Were it not for those, we wouldn't have to keep TAP keys around any more -- and TAP keys would bloat SNIPs to a pretty huge degree. The best answer here seems to be migrating our legacy HSv2 services so they can use ntor onion keys for intro and rendezvous points. That would also need to be done in a phased way. [TAP-OUT-AGAIN]. The alternative way to keep HSv2 working with walking onions would be to allow TAP keys to be distributed as part of the SNIP system. That seems like a fair amount of work, though, and unlike using ntor, it wouldn't have any positive benefit. ((Yes, HSv2 is deprecated. But I don't want to give people who still use it a reason to avoid the walking onions transition.)) == Relay honesty and ENDIVE swapping One of the issues with our current directory system is that multiple consensus network documents are valid at the same time. In practice, clients will accept fairly old documents, to avoid running into trouble if the authorities have failed to vote. But this client behavior gives hostile directory guards an opportunity to select which of several recent documents to serve. Walking Onions would make this problem worse, since every relay, when it serves a SNIP, is serving part of a directory that it knows a client is about to use. If we did nothing to mitigate the problem, then hostile relays could mount an "ENDIVE swapping" attack where they look at a client's choice of routing index, and then see whether any live ENDIVE contains a SNIP that the attacker likes at that position. In [HONESTY] I described a few responses to this problem. The first is that we should limit the rate at which the index layouts change. The second is that all parties that look up SNIPs through a relay should verify that the "published" times from each relay are monotonically increasing. The third response seems like the most useful to me: we would recognize that under ordinary circumstances, the permissible lifetime for an ENDIVE would be much shorter than it would be under emergency (consensus failed) circumstances. That is, if everything is going well, each relay should get a new ENDIVE every hour or so. Only if there is no new ENDIVE should clients accept SNIPs that are extremely old. With this in mind, I'm proposing a rule that if a client sees _any_ valid SNIP published at time `T` or later, it should not accept any SNIP published before time `T-Delta`. (Delta is a network parameter.) With this rule in place, clients will insist on fresh SNIPs when the network is working well, but will tolerate old ones if the authorities are failing to reach consensus for a while. == More questions of migration One hard step in any proposal is dealing with migration questions. I've stared to try to lay out a timeline in a new section [MIGRATION]. This part isn't looking great to me right now. It seems like it won't be safe to turn on Walking Onions for clients until it's supported by most relays. Moreover, clients that use Walking Onions won't be able to use relays (or at least, non-exit relays) without support for it. This implies a longer migration path than I'd like, but I don't see a way around it. == And what about families? Our existing family representation is quadratic in family size, since every relay needs to list every other relay in the family. This gets worse with Walking Onions, since SNIPs can't benefit from compressing the repeated family entries. At first I had hoped to use some kind of a max-clique algorithm to infer the families at the authorities, and then encode clique identifiers in the SNIPs. This isn't such a great idea, though: I wasn't able to persuade myself that an adversary couldn't force the authorities' burden to become exponential here. Instead I think we should resurrect proposal 242, in an improved version [BETTER-FAMILIES]. Instead of having to list every node in a family, each relay in a family would include a signed certificate from a "family key" attesting to their membership in the family. The proposal addresses some tricky compatibility issues. == Coming up next This week is going to be rather busy on my end: I'll be a bit startled if I get very much done with Walking Onions at all. My hope is to edit the proposal, fill in gaps, and address pending comments. [BETTER-FAMILIES] https://github.com/nmathewson/walking-onions-wip/blob/master/other-proposal… [HONESTY] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/08-track… [MIGRATION] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/09-migra… [ONIONSPEC] https://github.com/nmathewson/walking-onions-wip/blob/master/specs/07-onion… [TAP-OUT-AGAIN] https://github.com/nmathewson/walking-onions-wip/blob/master/other-proposal…

1 0

Building a privacy-preserving "contact tracing" app
by Adrien Luxey 24 Apr '20

24 Apr '20

Hi all, The French state is making a glosing about the "privacy-preserving", "anonymous" contact tracing app they are developing with Inria (national informatics research agency). You can check about the protocol proposal, ROBERT, here: https://github.com/ROBERT-proximity-tracing/documents (in English!) As you would expect, the proposal is not privacy-preserving unless you believe the State would never ever misbehave, e.g. link IP address to identity with the help of ISPs etc. There is some relevant criticism here: https://github.com/ROBERT-proximity-tracing/documents/issues/6 I'd like to propose a really private "contact tracing" counter-proposal, which would use Tor's onion services for sender-receiver anonymity. Not that I am a proponent of the idea, but we need to come up with alternatives in the debate. My question is: /would the Tor community agree on having StopCovid's traffic go through its net?/ In my proposal, I would only broadcast a message from a declared COVID-positive person to all its recent contacts; the proximity sensing would remain Bluetooth. Still, deployed at the scale of a country, it's a lot of traffic. Thank you for your time, I will keep you posted, Adrien

4 3

Proposal 314: Allow Markdown for proposal format.
by Nick Mathewson 23 Apr '20

23 Apr '20

``` Filename: 314-allow-markdown-proposals.md Title: Allow Markdown for proposal format. Author: Nick Mathewson Created: 23 April 2020 Status: Open ``` # Introduction This document proposes a change in our proposal format: to allow Markdown. ## Motivation Many people, particularly researchers, have found it difficult to write text in the format that we prefer. Moreover, we have often wanted to add more formatting in proposals, and found it nontrivial to do so. Markdown is an emerging "standard" (albeit not actually a standardized one), and we're using it in several other places. It seems like a natural fit for our purposes here. # Details We should pick a particular Markdown dialect. "CommonMark" seems like a good choice, since it's the basis of what github and gitlab use. We should also pick a particular tool to use for validating Markdown proposals. We should continue to allow text proposals. We should continue to require headers for our proposals, and do so using the format at the head of this document: wrapping the headers inside triple backticks.

1 0

Re: [tor-dev] Chutney code refactoring
by c 22 Apr '20

22 Apr '20

On Fri, 17 Apr 2020 18:01:42 -0400 Nick Mathewson <nickm(a)freehaven.net> wrote: > If you want to work on this it would be helpful to maybe start by > listing (here or elsewhere) some places where you *don't* feel like > you could (or would want to) write documentation: those would be a > good target for devs who _have_ worked on Chutney before. Sounds good, I will work on this. > Though I think this is likely to be an ongoing change that we see > over time, since Was this sentence supposed to be longer? > * More tests for the various parts of chutney, and refactoring to > make them more testable. Internal unit testing seems like a good idea, yes. > * Making chutney comply with one or more of the python style > checking tools that are out there. I can look into this; personally I have no experience with Python style-checking or linting tools, but now's a good time as ever for me to learn what is available and how it would work for Chutney. > This is an good vision for how Chutney should go; I really support > this idea. Glad you are on board :) Caitlin

3 2

Fallback Directory Handover
by teor 22 Apr '20

22 Apr '20

Hi all, Here's a summary of the current state of fallback directory mirrors. Overall Design This repository contains a list of potential fallback directory mirrors (a fallback "offer list"), and a script that checks each mirror for speed and reliability: https://gitweb.torproject.org/fallback-scripts.git/ There is a "Fallback Scripts" component for tickets: https://trac.torproject.org/projects/tor/query?status=!closed&component=Cor… The fallback system is designed to gracefully degrade as fallback directory mirrors fail. Failures shift load to directory authorities, and cause brief delays during client bootstrap. We expect the system to operate well, even if all the fallbacks have failed. But we try to keep the fallback failure rate below 20-30%. When the failure rate gets too high, we rebuild the fallback list. Regular Tasks This ticket is the parent ticket for the next fallback rebuild: https://trac.torproject.org/projects/tor/ticket/30971 This ticket contains the "offer list" changes that relay operators have requested. I usually commit them all at once, but you should feel free to do them incrementally: https://trac.torproject.org/projects/tor/ticket/30972 Sometimes, we don't have enough relays on the offer list, and we have to ask relay operators to opt-in to the list. Ideally, we want at least 100 fallbacks, we usually have between 120-160. Future Work It's hard to verify changes to the offer list. Changes are usually sent by email or through trac tickets. There's no reliable trust path from the relay key to the email or ticket. The opt-in process is also a manual process. It can be time-consuming. To resolve these issues, I had planned to add a signed fallback offer line to relay descriptors: https://trac.torproject.org/projects/tor/ticket/24839 Instead of checking the list in the fallback-scripts repository, the script can check relay descriptors instead. (Or check both, during the transition period.) Unresolved Issues Fallbacks eventually see the entire set of clients. Clients that are active all the time may only ever contact one fallback. (Clients re-use the same fallback for authority keys, and then switch to the consensus as soon as possible.) But clients whose consensuses have expired will choose new fallbacks at random. Ideally, clients should select fallback (and maybe authority) guards. That is, they should retry previously-selected fallbacks. There are some tradeoffs here: a bad fallback guard can continue to manipulate its client's view of the network. We can avoid this issue by selecting multiple fallback guards. Clients will need persistent state to remember their guards, so transient systems like TAILS won't benefit from this change. T -- teor ----------------------------------------------------------------------

2 2

Walking Onions: week 7 update
by Nick Mathewson 17 Apr '20

17 Apr '20

Walking Onions: week 7 update On our current grant from the zcash foundation, I'm working on a full specification for the Walking Onions design. I'm going to try to send out these updates once a week. My previous updates are linked below: Week 1: formats, preliminaries, git repositories, binary diffs, metaformat decisions, and Merkle Tree trickery. https://lists.torproject.org/pipermail/tor-dev/2020-March/014178.html Week 2: Specifying details of SNIP and ENDIVE formats, in CDDL. https://lists.torproject.org/pipermail/tor-dev/2020-March/014181.html Week 3: Expanding ENDIVEs into SNIPs. https://lists.torproject.org/pipermail/tor-dev/2020-March/014194.html Week 4: Voting (part 1) and extending circuits. https://lists.torproject.org/pipermail/tor-dev/2020-March/014207.html Week 5: Voting (part 2) https://lists.torproject.org/pipermail/tor-dev/2020-April/014218.html Week 6: Editing, voting rules, and client behavior (part 1) https://lists.torproject.org/pipermail/tor-dev/2020-April/014222.html == Clustering exit ports This week I tried to figure out how exits work with walking onions. A naive approach might have 65535 different routing indices in the ENDIVE (one for each TCP port), but that would give horrible performance: it would make the expanded ENDIVEs absolutely huge. Instead, we can cluster ports into "classes" based on which are always supported or not supported together. (For example, on the day I scanned the directory, every relay supporting any port in the range 49002-50000 supported all of them.) There are about 200 such classes on the current Tor network. But 200 exit indices is still probably too much: it seems like we'll need to cluster exit ports together in a more lossy way. For example, not every exit that supports port 80 supports port 443 or vice versa. But around 98% of them do -- so it we wouldn't be losing too much by using one exit index for "443 and 80", and not listing the 2% of exits that only support one of those ports. I wrote a short program [EXIT-ANALYSIS] to experiment with clustering strategies here, and settled on a greedy algorithm to get down to a smaller number of port classes by iteratively combining whichever pair of classes will cause us to lose the fewest number of (relay:port) possibilities. We can get down to 16 classes and lose only 0.07% of all the relay:port possibilities; we can get down to 8 classes and lose only 0.2%. That's not the whole story, though. Some of what we're losing would be things we'd miss. When the algorithm gives us 16 classes, it loses 75% of port 10000, 70% of port 23, and so on. Clearly not all ports are equivalent, and we should tune this approach to take that into account. We should also consider the bandwidth impact of these changes, and retool the algorithm so that it minimizes the bandwidth-per-port combination we have. We'd also likely want to hand-edit these port lists so that they make more sense semantically on their own. That way, we could take Teor's suggestion from last month and try to give exit relays the options to opt in to or out of human-intelligible partitions. Further, we could save some complexity by requiring dual-stack exits to support the same ports on IPv4 and IPv6. That way we wouldn't need to worry about divergent sets of port classes. == So what do we do with these clusters? If a client wants to connect to port 25, and uses a port-25-only index, that leaks the client's intention to the middle node. That's not so good. Instead, in the tech report [WHITEPAPER], one or both of Chelsea Komlo and Ian Goldberg came up with a mechanism called Delegated Verifiable Selection (DVS). With DVS, when the client sends a BEGIN cell, the relay can respond that it does not support the requested port, along with a SNIP from a relay that does. To prevent the relay from choosing an arbitrary SNIP, the BEGIN cell would have to include an auxiliary index value to be used when DVS is in place, and the END cell would need room for a SNIP. (Alternatively, clients could just make a 3-hop circuit and ask it for SNIPs to be used as exits on some other circuit.) == Voting on policy sets These policy clusters (and a few other things!) are too complex for the voting operations I had before. Fortunately, it's safe to treat them as opaque. I've added a new voting operation to allow authorities to vote on a bstr that is then decoded and treated as a cbor object (if it is valid and well-formed). It should be useful in other places too. == Migrating port classes Migrating from one set of port classes to another is nontrivial. Clients who have the old root document will expect the indices to correspond to one partition of ports, whereas clients with the new root document will expect another partition. To solve this, I've designed the system so that two sets of exit indices can exist concurrently while clients are moving to the newer partition of ports. Alternatively, we could give SNIPs a mechanism to contain a field saying "Your root document must be at least this new." I don't know which approach would be simpler; both seem like too much complexity for a feature that would only be used occasionally. == Next steps My next plan here is to write up onion services; I believe I've got the design there mostly figured out, and just need to write it down. After that, I'm planning to turn back and fill in all the missing subsections that I've written so far, and write a short introduction. There are a lot of missing sections, so that won't be super fast. I'm also going to need to show the whole thing to a beta reader or two to answer the question, "Would this make sense to somebody who doesn't already know what it says?" == Fun facts The script to generate exit port classes [EXIT-ANALYSIS] was written in Rust. If I'm counting right, it's only my second Rust program that actually does something useful! If you are one of those Rust enthusiasts who would like to critique it, I wouldn't mind at all -- just send me comments offline or make notes on the repository. (Only do this if you like critiquing newbie Rust that was never actually meant for production use. Don't do this if you just want to point out all the things that make it unsuitable for production use.) == Not-so-fun facts This week I've been fairly overwhelmed with the lead up to and down from the recent layoffs at Tor, in response to a downturn in funding during the COVID-19 pandemic [BLOGPOST]. Tor will continue, and this work will continue with it--but it is still a hard blow to have to lose so many excellent coworkers. (Yes, I'm still at Tor, for the record.) Do you know somebody who is interested in hiring one or more amazingly talented programmers, engineers, communications specialists, or project managers -- all with experience at productive remote work and all with dedication to improving people's lives? Please pass their information along to tor-alums(a)lists.torproject.org , and it will (after moderation) get forwarded to those affected. [BLOGPOST] https://blog.torproject.org/covid19-impact-tor [EXIT-ANALYSIS] https://github.com/nmathewson/walking-onions-wip/tree/master/exit-analysis [EXIT-PARTITION] https://lists.torproject.org/pipermail/tor-dev/2020-March/014182.html [WHITEPAPER] https://crysp.uwaterloo.ca/software/walkingonions/

1 0

Chutney code refactoring
by c 17 Apr '20

17 Apr '20

I was going to mention this on my pull request <https://github.com/torproject/chutney/pull/67> but I figured it would be much more fitting to have a more-general thread here. In the PR I mentioned how I believe that, if it quacks like a dict, it should be implemented as a dict. That way we (hopefully) run into fewer gotchas down the line, trying to reinvent the dict ourselves, and we have clearer self-docuemtnation ("oh, this class inherits dict, now I know kind of what to expect out of it"). I'm still trying to reason through chutney's code for how exactly inheritance works and how this inheritance can be expressed more clearly, for example it looks like the `Node` class is for a type of relay (authority, client, bridge, et cetera) and its `getN` method is to generate a number of those nodes. That is poorly documented and I only figured this out by seeing how `Node.getN` was being called in the tests themselves. To me, it makes more sense not to "overload" what a `Node` is; if we are using an object as a factory to create more `Node`s, then we should make that evident. The factory can then make identical nodes with similar properties, rather than one parent `Node` spawning children that refer back to their parent. For me this issue is mostly "it feels like a lot of mental overhead, and I'm sure it can be done better than it already is." But of course it's difficult to fix something without first understanding how it should behave. (Perhaps a test suite for the test suite? ;) But since we're dealing with a lot of inheritance in chutney, and since this inheritance is (in my opinion) expressed poorly, it can be quick to find oneself caught in a web of code with no clear way out. Here is what I have been considering lately, with the code overall. I hope that laying it out in points will help both myself and others try to divy up what could be improved about the code, work on it piecewise, and make sure nothing is reimplemented incorrectly. I know I'm new to the code and thus have not looked into it thoroughly enough to understand everything about it, but again, something in the back of my head is telling me that if it's this difficult to understand now, then it can stand to be changed. So please take my criticism lightly and only where it applies. I could be wrong about some things as well. But, as a testing suite, this is the place we absolutely need to be sure we get right, because with a hard-to-reason testing suite, we open ourselves up to bugs within the tests themselves. - Documentation especially for methods that the tests are supposed to call. In `Node` class, there is a comment "Users are expected to call these" with `__init__` and three other functions declared. `__init__` is fairly self-explanatory but the other three could stand to have the same docstrings that we are giving other functions. I think this should be my first task, before trying to mess with anything that moves. That way, we have a clearer overview of the testsuite's API, and then we can work the implementation around that. - Once it's clear to all of us (meaning, not only the core Chutney devs, but also outsiders such as myself) what the current interface does, we can see the strengths of that interface, maybe some design flaws if we deem any to exist, and some improvements we can make with the interface. What I mean is: here is the place to make any necessary adjustments to the API before we dive into implementation. - Now we visit the implementation. By this point I (and other non-core developers) should have a better understanding on what the tests *should* be doing, that we can then proceed to verify the correctness of the tests' implementations themselves. Here's where I would like to revisit cleaning up the code so that we make use of functions to abstract and "atomize" certain aspects of the code (like the currently-unused function isBoostrapped), where we should introduce more self-documenting names (as suggested, replace getAttribute names with isAttribute names for when we want to return bool values), et cetera. I'm outlining what *I* think the approach should be, and in hopes that everything else will line up and make more sense for us all. I do want to make sure I know what the code should be doing, because while I could inspect the code line by line and go through the logic branches myself, I'm going to be perfectly honest and say it gives me a headache :) I think it's much easier to reason about with compartmentalised, self-documenting (and docstringed) components, than to try to step through the code as it runs and take it in as one giant piece. Because, we're testing a complex piece of software (Tor). Tor itself can do a lot of things that can throw us off especially if we're less familiar with its implementation, yet. And that throws off our understanding of how Chutney is supposed to work, as well. A lot of the tests currently seem to be very conditional -- they pass or fail with little rhyme or reason, which is of course the best type of issues to debug :P -- so I don't see the test results helping me as well as refactoring the testsuite first. Again, let me know if I have anything wrong, made any unjust assumptions, showed my ignorance, et cetera. I'm going into this boldly and I hope that's the right call. Caitlin

3 2

Re: [tor-dev] Chutney code refactoring
by c 16 Apr '20

16 Apr '20

On Thu, 16 Apr 2020 20:12:18 +0400 meejah <meejah(a)meejah.ca> wrote: > As to the specific DictWrapper issue, I also found this confusing. It's > kind of tied into a custom templating system too. I would question > whether this is a good idea; there are many templating systems already > for Python -- what does Chutney's add that these don't already have? That's why I want to understand what Chutney is trying to do exactly so maybe I could find some pre-made wheels (no pun intended toward the package format) in Python's ecosystem that will fit the vehicle, rather than reinventing it. That is, of course, if such wheels make sense for Chutney to use. One thing I love about Python is its mature ecosystem. > While re-factoring I would try to reduce the amount of inheritence where > the user has to understand it to make progress. For example, any API > where a user is expected to override a class and re-write some methods. Agreed, I will keep this in mind. > I'd have to delve back into Chutney to give more specific suggestions, > but wanted to chime in and say that I also found it confusing and hard > to read Python :) So far your suggestions have been helpful, so thank you. Caitlin

1 0

Choosing a valid Circuit ID for an OR connection
by Eli Vakrat 14 Apr '20

14 Apr '20

Hello to the TOR dev team! My name is Eli, I'm a high school student from Israel and I'm currently trying to implement a TOR Client in Python. Currently, my project is configured so that the python client (OP) has its guard node set as my local machine (which is running a downloaded version of TOR). I do this for debugging purposes so that if I send a malformed cell as the implemented client, I can read the debug log that the OR generates and see what I did wrong. As I am writing this, I have successfully been able to make a v3 "in protocol" handshake by sending the proper VERSIONS and NETINFO cells that the OR has accepted. Right now, I am working on getting the CREATE cell to work (with the TAP handshake), and when I send the cell to the OR It sends a DESTROY cell with the following message in the debug log: Apr 14 12:24:51.166 [warn] Received create cell with unexpected circ_id 1. Closing. To my understanding, the problem here is that the circuit id I have chosen is not valid. I read from the tor spec that there is a range of acceptable circuit id's for each relay and it can be found in the long term 1024 bit RSA "signing key". My question to you all is, how can I extract that range for the circuit ID's (along with any other relevant information) from the signing key? In other words, what is the "signing key" made up of, and how can I get the information that its made of? The bottom line is I need to find out what valid circuit ID's I can send to OR's. I am having a lot of fun doing this project so far and I hope to hear back from anyone who has an answer :) Thanks in advance! Eli

2 1