[tor-dev] 2nd status report for OnioNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello everyone, Work on the Onion Name System (OnioNS) continues. As stated in the previous status report, my primary focus now is separating the server components. In the last release, a single name server handled everything, making it a centralized system. I have made significant progress in seperating roles such that one machine acts as an authority while another machine returns Records and digital signatures to clients. This reduces the loads and responsibilities and is the key step towards creating a true distributed system. During implementation, I decided the scrap the Snapshot data structure and its protocol. A Snapshot is basically a server-side short-term cache of Records that is then flushed out periodically. The issue is that in the event that two HSs claim the same name within a short time period of each other and transmit their Records to two different Quorum nodes, when the Snapshots are flushed out it's non-trivial to decide which one took precedence. Snapshots were originally intended to save networking costs and reduce the risk of timing attacks, but in the end I realized that it didn't actually reduce networking costs, and timing attacks are an acceptable risk given Tor's design and threat model. So instead, servers can now subscribe to other servers for network events. If server B is subscribed to server A, when a Record is transmitted from a HS through a Tor circuit to server A, it sends the Record to B immediately. Thus all Quorum nodes will subscribe to all other Quorum nodes, and Mirrors can subscribe to one or more Quorum nodes, and Mirrors can subscribe to other Mirrors. This allows new information to propagate across the network immediately. This simplifies some of the protocols and fixes a significant problem. I have also made significant progress on logging events to file, rather than to std::cout. I am also planning on loading networking information from a file, simulating a Quorum, maintaining a debug package, and launching the software with the Tor Browser. I have made progress on all of these and have listed them in a milestone, scheduled to be included in the next major release: https://github.com/Jesse-V/OnioNS/issues?q=is%3Aopen+is%3Aissue+milestone%3A0.3.x See you at PETS! - - Jesse V. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVhhTEAAoJEK2XNk/CC+yAIdMH/AlUiqCFsQCESe1I6tUzYfHO 4DLTZGVInSC1AMjhdO4RBLuO/MZuZgGAzsitI65KEOkYBAFd7TGOu8DMDbfU9tdt d9yRVshqP/LSd9b9/WmmVZTq0zazkZDOBYELcrXBw3ic4tu+HdJ5E3yl/Fm2bE5C eu0gVbBipvbj332cypqf6J2xpP5gQN5pdSLh+AHRqgMN1K9huTw/yq2/Kgu2ZmhX 8AoMerNmkQ9Wj+tUcyW+Ab9+SFUrkeYUxPp60WVXXciD311uUhKTKknGjRDgBNZw YSI/2RrHkW2342XfvaiI7qbgfnSKQx5yko9KxV2ab1JSpzgocgutWRjwSZFIt/M= =rqna -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] 1st status report for OnioNS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 For this first status update on my SoP project (the Onion Name System), I'd like to give a quick run-down of where the project currently is. I would consider OnioNS ahead of schedule as I made significant progress on it for the paper before the SoP program officially began. The following features are in place: *Client-side:* * A reliable Stem script that intercepts a .tor domain and sends it to the OnioNS client. It sets Tor to leave streams unattached, then auto-attaches non .tor streams, and rewrites .tor to .onion before attaching. Thank you arma! * Reliable IPC communication over a localhost TCP socket between the Stem script and the OnioNS client. The IPC syntax is simple enough to support telnet or other tools. * Ability to specify the IP of a name server (essentially a Mirror, but the name server isn't mirroring anything since the Synchronization protocol isn't there yet). * JSON communication over a Tor circuit (SOCKS username OnioNS) to a name server. * The ability to verify the signature and proof-of-work of a Record. *HS-side:* * The capability to create and validate (through scrypt proof-of-work) a Record. * Prompts to allow a user to specify the domain name and subdomain-destinations that they want for their hidden service. * The printout in JSON of a Record, which one can copy and send over email or IRC until I get the upload protocols in place. *Server-side:* * JSON communication to make life easy. * TCP server for receiving a .tor domain and returning a Record. * Support for multiple Records. * The ability to accept and cache a new Record. * Construction of a Merkle tree and RSA-signing of the root. * Ability to find a Record in the Merkle tree, or to find a subtree that proves a domain's non-existence. *General:* * A hidden service for this project. * Reliance on Botan rather than OpenSSL. The difference is night and day. Thank you Yawning! * A Record for example.tor and several others for testing and illustrative purposes. * Clean and organized code. The style is similar to Chromium with the exception that I put three spaces between each method. I enforce the style with clang-format. * A basic but functional manpage. * Support for Clang and GCC, with Clang being the preferred compiler for development and GCC is used when packaging. * Packaging into a PPA on Launchpad for Ubuntu 14.04 and beyond, so tor-onions can be installed and updated through apt-get. I also support Debian 8+ but do not currently package for it. * Packaging for x86, amd64, and armhf, so I'm supporting Pis/BBB/Odroid as well. * Many labeled tickets on Github to improve workflow. * Signed git tagging. As you can imagine, this constitutes the bulk of the essential functionality. The remainder is primarily networking and server-side protocols, such as the Quorum, the Synchronization and Broadcast (upload) protocols, various algorithms, and so on. Those are next. I'm temporarily in a remote location and the Internet here is slow and quite spotty, so the project's hidden service is down and I haven't tested the latest commits over the network. However, once I have the Internet figured out I'll post a prototype here that everyone can test if they like. It's a centralized DNS at the moment, so spreading it out is next on the list. - - Jesse V. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVcJMiAAoJEK2XNk/CC+yAPAAH/3uFvSXRwpq8QfE7o///Cc5a 5w3NwTP06pp1+AQ8RNUhmt17z3eHYOJJpP6zP4uwEzwAnNbUAs/8GiGdDOUj5Se3 kCUPh8/0s+yHWb02ctVhOYE32CouUVQHnswtuDRjz9KPO9Z3yG2d16TUINOurfKf tigUlgrRaW5pOIm0CQ2z4epi7FFKwdPjdTpsdbZURZTwybCiS4vgfN08iaIRZ/3M 9tz1tfQZH303yTQwubdYf9l99XJlxBtFBFjJlJzCze7iOEVD+j0fHRKk6OM/wouD kjKrarEQQACQhUzNssAr2/Yv/odYvshJYSLe/7/eoGH7zkKof0rbcBQPyLUpZoU= =B+Hz -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The Onion Name System (OnioNS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 What's to stop a sybil attack where the malicious relays try to occupy likely site(s) for the next Quorum? Is the consensus unpredictable enough to thwart this attack? Even during quiet times? (Does Tor have quiet times?) As you can see from the ACM paper, I estimated 16Kb - 28Kb from routers leaving/joining the consensus, and my Markov Model analysis shows ~9000 bits from routers changing in some degree or another. Certainly the size and dynamics of the Tor network are enough to put the entropy above 256 bits, so I'm confident that any sort of malicious maneuvers (such as changing router descriptors so that the SHA-384 hash results in an attacker-pleasing Quorum) is hard because of the cryptographic defenses of SHA-384 and because the consensus has a large degree of entropy. I believe (but cannot prove) that those numbers are a lower-bound, though formally it's just an estimation. Sybil attacks are possible but expensive. They would have to gain the Fast and Stable flags and be subtle enough to not be detected by the Tor community (the Lizard Squad learned that the hard way). Sybil attacks would also likely compromise Tor and hidden services, which is outside my security assumptions. Can we ensure the Quorum servers have to be long-lived and high-capacity (for example, guards) to make it harder to spin up servers and immediately be added to the Quorum? I'm not convinced the Stable flag is hard enough to get. Of course, there's a trade-off where making the set of Quorum Candidates too small makes the Quorum easier to predict, too. One possible counter-measure is the Sybil attack detector that was posted here the other day. It might be a good idea, I'll think more about that. By the way, in your ACM paper 5.4.2 you switch from Charlie to Alice, but I think they're meant to be the same Quorum Candidate. Thanks, I'll take another look. Alice is always a Tor client. The HS is down, and has been for some days. Yes. I'm currently hosting it myself and I'm currently but temporarily in a remote location where the Internet is spotty at best. By the time I deploy OnioNS into beta or into production I'll have a stable host for the HS. I'll have it up soon. In the meantime, you can always clone and browse the Github repo that powers it, OnioNS-www. I have two questions about the Stem-based approach: 1. Applications which use Tor via SOCKS won't be able to use .tor domains without using Stem. This adds another dependency to apps which want to use .tor addresses, and confuses users by making .tor addresses work with some torified apps, and not others. Is your final goal to have .tor lookups contained within the Tor client? I'm sure someone could help with the C coding if that's the issue, particularly given a working implementation in Python/Stem. If a user wants to use a .tor address with something other than the Tor Browser, they will have to have both the Stem and the OnioNS client software running in the background. It should be application-independent. Eventually I would like the Stem code in the Tor client, and theoretically it should not be hard to do so. Currently I have a very reliable Stem solution (for which I am very thankful) and I will be utilizing that script for the time being. Based on a quick investigation it should also be easy to auto-launch it with the Tor Browser. I would like to see the OnioNS package in Linux or Tor repositories so that it may work as a general solution, and not something tied to the Tor Browser. 2. I always feel nervous when people say letting app X spin. I assume Tor Browser just looks like it's doing a DNS lookup or similar? I may have misused the term. It's not a busy-wait. Currently it's an idle synchronous wait on separate thread in the Stem script. The Tor Browser appears as if it's waiting for a DNS lookup to occur, which is essentially correct. Once that goes through, Tor attaches the stream to a .onion address, and the browser transitions to appearing as if it's waiting for a server over a high-latency connection, which is also correct. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVbg1lAAoJEK2XNk/CC+yAnxEIAMn+XvrKX02+1OGrxQe4poNu hJzDcZHIJ5GTkYJk6iIOu7J+riz/f7rmQbvtxJWt3ZcAfebqcoec0j1kbvnFWDP4 /C35A4nSEN36XlDU/5AkYHv6l5dgvvxX+cDMSvHKFzrZU2m4uGAi5QF4qr3dqbbB ys6i1d4x/kuPvfFvZVrsiFVO0EKK5EzunccxHfly4aOpzksJlTCSrKSWoDwltpOK F9UKww53JTPbfNTMmqnOx9sE6DuPz3mNA7DMTMBiPjhl9nouq4mGFma60up2XY/u Ge9qOE7Wrrn95H9JZAR3uQqi5CehnAFd9h2fC2mcyAGkppJ69oOLhIBi/z94hC0= =Fygz -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] The Onion Name System (OnioNS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/20/2015 12:18 AM, tor-dev-requ...@lists.torproject.org wrote: Furthermore, there is the question of time. As .tor-names are pinned (if you have a name, you get to keep it 'forever', right?), an adversary may invest into the required resources to make the attack succeed* **briefly* (i.e. get the required majority), then re-assign names to himself. New honest nodes would pick up this hacked consensus, and thus it would persist even after the adversary lost the majority required to establish it. This is relevant, as an attack against Tor user's anonymity only impacts the users as long as the attack itself lasts, so the gains between the two attacks (temporary vs. forever) change the economic incentives for performing them. So I'm not sure it is such an obvious choice to just rely on an honest majority of (long-term/etc.) Tor routers. I'm not saying it is bad; however, simply saying that if those routers are compromised all is lost anyway is not quite correct. To carry out the attack you describe, they would need to have control of enough colluding Tor nodes so that they control the largest agreeing subset in the Quorum. It's not about PoW to control the Quorum, the Quorum is a group of Tor routers. My design also assumes that there is no dynamic compromise of Tor routers (there's no incentive for an attacker to target Tor routers because of OnioNS) so we can consider a static level of compromise. As I've shown in my analysis, if the Quorum is large enough, the chances of selecting a malicious Quorum, either per-selection or cumulatively, is extremely low even at Tor-crippling levels of collusion. Ok, let's assume a c4.xlarge EC2 instance (which is ~i7) takes 4h to do this (on all cores). For one month, the price is USD 170, which means the registration cost is 70 cents/name (for eternity, or do I have to do this repeatedly? Don't recall if you require a fresh PoWs). Anyway, 4h sounds pretty inconvenient to a user, but as you can see is still nothing for a professional domain name squatter who today pays closer to 100x that to squat for a year. I predict most 'short' names will be taken in no time if this is deployed. With Namecoin, you have an inherent limit on the rate at which names can be registered. Now, once people start squatting tons of .tor names, maybe even your bandwidth advantage disappears as the consensus may become rather large. That's a fair point. It's a hard problem to solve. It's subtle, but I also put in a requirement that the network must also ensure that the registration points to an available hidden service. Thus it forces innocent users and attackers to also spin up a hidden service. It's not foolproof, but it's better than nothing. I've also been thinking about a proof-of-stake solution wherein the network only accepts a registration if the destination HS has been up for X days. Another idea is to have the Quorum select a random time during the week, test for the availability of the hidden service, and then sign whether they saw the HS or not. Then the next Quorum could repeat this test, check the results from the previous Quorum, and void the Record if they also observed that the hidden service was down. I like both of these ideas, but I have not yet solidified their implementation so I was not ready to announce them in the paper. Well, I prefer my hidden services to be really hidden and not public. I understand that this weakness is somewhat inherent in the design, but you should state it explicitly. Too late, your hidden services are already leaking across Tor's distributed hash table. There are even Tor technical reports and graphs on metrics.torproject.org which count them, which I assume also implies that they are enumerated. I can't remember where I read it, but I do recall reading some report about how the researcher spun up a number of hidden services, didn't tell anyone about them, but then observed that someone connected to them anyway from time to time. Someone out there is enumerating HSs. Tor's HS protocol isn't designed to hide the existence of HSs, my system isn't either. I can state it explicitly, but there's no practical way around it as far as I can see. See, that's the point: Namecoin (and your system) assume a different adversary model than what Zooko intended to imply when he formulated his triangle. When Zooko said secure, he meant against an adversary that does have more CPU power than all of the network combined and unlimited identities. When you say secure, you talk about Namecoin's adversary model where the adversary is in the minority (CPU and identity/bandwidth-wise). Thus, it is unfair for you to say that your system 'solves' Zooko's triangle, as you simply lowered the bar. As you say, Namecoin assumes that it has more CPU power than adversaries. Perhaps I should have clarified more
Re: [tor-dev] The Onion Name System (OnioNS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/19/2015 03:20 AM, tor-dev-requ...@lists.torproject.org wrote: Subject: Re: [tor-dev] The Onion Name System (OnioNS) From: Christian Grothoff groth...@gnunet.org Date: 05/19/2015 03:24 AM To: tor-dev@lists.torproject.org Please write an IETF draft asking for .tor to be reserved for Tor under RFC 6761 referencing your documentation. Should take no time if you base it on Jake's .onion draft. Send it to dnsop, they really love to discuss this topic and alternative DNS protocol ideas right now. ^_^. I will put that on the to-do list. Also, GNS is not a hierarchical zone of names (no hierarchy, just a directed graph). Thanks, I'll make those corrections. Good to hear from someone who is part of that system. I'm not sure how your proposal significantly improves on NameCoin, except that it is specialized to Tor (and thus doesn't attempt to be as compatible with DNS as Namecoin): for security, you still rely on a PoW-supported consensus, so an adversary with sufficient computational power can register important names first (who gets facebook.tor first?). Given that you probably don't want to double the electicity bill of 'normal' users when they want to register names, my prediction is that if this is adopted, trolls (and name squatters) will have a field day registering interesting names. My scheme is better than Namecoin in several key ways: 1) No miners. I'm relying on the existing trust of the Tor network and purposely did not create a new network. 2) Minimal networking costs. Namecoin typically requires users to hold the blockchain, and has very little client-side security when users rely on name servers to hold it for them. I require clients to check a set of signatures from Tor routers. Most of the attack vectors for OnioNS also results in a compromise of Tor, which makes the whole thing moot. Hence it makes sense to rely on Tor. The PoW is only for registration, no one else does it. Yes, it is first-come-first-serve, but so is Namecoin. On the Internet DNS, someone with lots of money could buy up domains too (ISPs do this all the time). For well-known hidden services (such as DuckDuckGo) we could mark those names as reserved such that only the owner of that hidden service could register it on OnioNS, and let all other names be first-come-first-serve. I'm thinking of setting the proof-of-work relatively high, say four hours on an i7 or so. The reliance on scrypt and the complex of the domain registration should restrict this to CPUs. I didn't see a mechanism to transition a name from one RSA key/.onion address to another. Is that intentionally missing? Will users loose control over their .tor names when they rotate keys? I only have 12 pages, there wasn't enough space for that protocol. However, I have already created protocols for deleting, transferring, and updating Records. Domain registration uses the same private key as hidden services, so if the key is compromised, both are compromised and the security of the Record is moot. It also seems you are unconcerned about zone enumeration. Both your protocol on authenticated denial-of-existence and the entire consensus system suggest that it should be easy for a peer to enumerate all names in the .tor zone. I'm considering that all OnioNS data is public. There's no way to hide information in the Pagechain as Mirrors need to verify it. An attacker could also spin up a machine, synchronize with the network, and enumerate them anyway. Clients must also see the domain names in the leaves of the Merkle tree in order to authenticate Records or verify that the domain does not exist by finding two domains that alphabetically span it. I also can't hide the domain names in the Merkle trees via hashes because then I'm mapping unique names to a binary space that may have collisions. It's far easier to just consider the information public. Fortunately, there's no personally-identifiable information in the Pagechain, so there's no advantage in hiding the data. Why do you limit names to 128 characters, when DNS supports 253? For space reasons. Longer names introduce more storage and networking demands. The smaller choice shouldn't make any practical difference; I have yet to see a domain name on the Internet with a 253-character second-level domain. With respect to Zooko's triangle, I would point out that you define it differently than GNS does (and we checked with Zooko about the definition at the time). In particular, you assume that the adversary has limited computational power and doesn't dominate the consensus. For GNS, we assume that PoW is useless (adversary can do PoW for all memorable names) and that consensus is useless (adversary has majority). This is because in practice, governments do have more computational power than citizens, and when it comes to censorship it is important to protect minorities and
Re: [tor-dev] Namecoin .onion to .bit linking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 05/19/2015 10:02 AM, Daniel Martà wrote: I'm not familiar with Namecoin, but I thought I'd just point out that someone will be working on OnioNS, the onion name system, as part of the SoP in Tor. The person who will be working on it just sent an e-mail to this very list yesterday. You two seem to be after the same human-readable way to access .onion domain names target as you yourself described, so there might be room for collaboration. I'm aware of OnioNS, but haven't yet had time to thoroughly read the proposal. It's certainly on my to-do list, if nothing else for cross-pollination of ideas. - -Jeremy Yes, I'm here. Last year I explored Namecoin as a possible alternative DNS for Tor hidden services. I spent some time over it, but I also ran into the same problems previously mentioned above: how to link HS RSA keys to Namecoin ECDSA keys. I came up with two solutions: sign the Namecoin key with the HS key and embed that signature in the blockchain, or introduce a new blockchain that relied on the same cryptography as hidden services (RSA, Ed25519, ECDSA, etc, as long as they matched). As I mentioned in the ACM paper, it's non-trivial to build this correlation and I came to the conclusion that solutions would look more like a hack than an elegant solution. Moreover, even if the correlation could be built, it's impractical to require clients to download the whole blockchain before use, so you still have to address the issue of preventing name servers from lying. I hope you can see that it's a difficult problem. I think Namecoin could use a solution if you come up with one, and I would be interested in hearing about it. I came to the conclusion that Namecoin would not work and wrote something different. Namecoin does many things well and I took those good design ideas, but I also changed the setup to solve many of its weaknesses. Namecoin, GNS, and OnioNS are good alternative DNSs, each with their own approach. Let's see if we can work together here, we might be able to help one another. Jesse V. -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVW52lAAoJEK2XNk/CC+yAUtQH/1a9zZQK2XYsQofGt+qtrAA0 MZmBHMTC+lBLcpq1ZSIYCD+vJ8DEO1Aoqrzfj7RVsS5T1dfXZ5B4D+u2XB+Obg1+ uW86/cWQ3S2UgFRg5Mg0+6C+3T7sIwBya3foXg0/dETh4R9J2QzSG7iobsvjuivr TEUh7iGl+9zBDHad3s5ZZRBms9ZHk4fQy1ckFx6h9bvh5ybzaZZKc8bAYdRF1yTi RQw4MmtoJ4e2MZf7Ze9qVn863KOLQQzOlw0ddQ4tCLpHfBwr+l+lK5waGflVYLjU C2RVt9QUS83PgDXY3sKp+kIlfqp0Oupf7ZFqq6xAHWIHORvcr8vERtFadWLiQVw= =vl1G -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] The Onion Name System (OnioNS)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello everyone, I'm the one behind the Onion Name System (OnioNS), a Tor-powered distributed DNS for Tor hidden services. It's been several weeks since my project was selected for the SoP program, and I've finally got around to posting here about it. My project aims to solve the major usability issue that has been with hidden services from the beginning: their un-memorable addresses. I'd like to discuss a bit about how it works, where my project is described, and where I am with the implementation. Under OnioNS, a hidden service operator can anonymously claim a meaningful domain name for their hidden service (a map between the .tor and .onion pseudo-TLDs) and then transmit it over a Tor circuit to an OnioNS server, which is also a Tor router. The claim propagates across the Tor network. Later, a user may type a .tor domain name into the Tor Browser. My software intercepts this domain, performs a lookup over a Tor circuit to an OnioNS node, and learns the corresponding .onion address. Then it tells the Tor client this, which contacts the HS in the normal way. The result of this process is that a hidden service loads transparently in the Tor browser under a meaningful name. I introduce several data structures, but the most important one is the Pagechain, a distributed structure of linked Pages. Pages contain Records, Records contain .tor - onion associations. Anyone who is familiar with blockchains will recognize the behavior and application of this structure immediately. However, here the head of the Pagechain is not managed by miners, but rather by a short-lived subset of Tor nodes called a Quorum. They receive Records and merge them into the Pagechain. At the moment I've decided to use 127 Quorum members and rotate them every week. They are randomly selected, but the process is deterministic; I am using the cached-certs + cached-microdesc-consensus documents, which everyone has, to seed a PRNG that then derives the Quorum. Clients don't need a copy of the Pagechain to use the DNS, but rather they can just rely on their existing trust of the Tor network (including the Quorum and name servers) and verify their signatures on data structures. Also unlike a blockchain, my Pagechain has a finite length: the oldest Page will eventually drop off, which forces domains to be renewed periodically. I have also introduced mechanisms that 1) allows clients to authenticate the domain name to the hidden service, 2) allow clients to authenticate a denial-of-existence claim from a name server, and 3) prevent name servers from forging .tor - .onion associations. These vulnerabilities are still generally open on the Internet DNS. I have also tried to minimize networking costs, since Tor circuits are slow. To reduce CPU and network requirements, I want Tor routers to have Ed25519 keys. Let this project add additional pressure on that item on the to-do list. Recommended readings: http://onions55e7yam27n.onion -- the official hidden service for this project, but a work in progress. https://github.com/Jesse-V/Thesis/blob/master/conference/acm-ccs.pdf -- the ACM paper pending peer review I no longer recommending reading my original thesis, please use the above links instead. My prototype can be found here: https://github.com/Jesse-V/OnioNS It's a bit unstable, but it does work once and sometimes twice. Please contact me (kernelcorn on IRC) before running the prototype, I need to ensure that the name server is up before you can try it out. You can also send me registrations over IRC and I can add them in. I am asking for help with the client-side functionality. I'm currently doing the *.tor interception and lookup resume in connection_edge.c but the software frequently crashes with this approach, (I've learned why) and I'd like to migrate it to Stem for now. I need to intercept .tor domains, pause the lookup (letting the Tor Browser spin), send the hostname over a named pipe or TCP socket, read back a .onion address, then tell Tor to resume the lookup under the .onion address. This way, the HS loads under a .tor domain. All other lookups should load as normal. I've never used Stem before but I understand using it will be a lot easier than hacking Tor. I have Stem up and running now. Any recommendations for what I'm trying to do here? - -- Jesse V. (kernelcorn) -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVWnpiAAoJEK2XNk/CC+yA0MsH/Ahg3V1U+bIRqawmVu5Ju85C gAqVqJx3pYsJPDHpmZU2OGICGIAWVMS0d8wA39H42MBJG3AP/1PGevlB8tK+/i5K t/o3vLTt9WpuxL3Lf2+VihlDTFnUSQz+02pMyghwjS3ANoutoLb2wMB/EeSn74FS ozLjEkO7fbyEx1Qzp4xDHKNjfRBmkn2k83O9YhEPZ6d6VYFHrCfsygd6XvHpuPzT XLu3OyamFeT5BjZgkX2gge+zG9UUOmDLC2aCQa83gHxcty3Sdh5aZ33oVfx9bROU +AaD2yAbLNaq/mEmp2qaAOnsQCzBTrRJ5CX9jyLvCOVYi3SZtl/4Ju/oomWqHl0= =TvQm -END PGP SIGNATURE-
