tor-dev May 2015

tor-dev@lists.torproject.org

54 participants
52 discussions

OpenWrt cross compile build error in 0.2.6.8
by Lars Boegild Thomsen 24 May '15

24 May '15

Hi Everybody, I have for a while been maintaining an up-to-date Tor package for OpenWrt. In the latest stable 0.2.6.8 I get a build error (see below). I suspect this is actually autoconf related and I must admit I am not too familiar with autoconf. I have been trying to compare things with 0.2.5.12 (which compiled cleanly) but I have not been able to spot or fix the problem. Any ideas? I am sure I miss something blatantly obvious. ccache_cc -DHAVE_CONFIG_H -I. -I./src/ext -Isrc/ext -I./src/ext/trunnel -I./src/trunnel -I./src/common -Isrc/common -I./src/ext/trunnel -I./src/trunnel -I./src/or -Isrc/or -DSHARE_DATADIR="\"/usr/share\"" -DLOCALSTATEDIR="\"/var\"" -DBINDIR="\"/usr/bin\"" -I/home/lth/ionic-router/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/include -I/home/lth/ionic-router/staging_dir/target-mips_34kc_uClibc-0.9.33.2/include -I/home/lth/ionic-router/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/usr/include -I/home/lth/ionic-router/staging_dir/toolchain-mips_34kc_gcc-4.8-linaro_uClibc-0.9.33.2/include -I./src/common -I/home/lth/ionic-router/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/include -I/home/lth/ionic-router/staging_dir/target-mips_34kc_uClibc-0.9.33.2/usr/include -Os -pipe -mno-branch-likely -mips32r2 -mtune=34kc -fno-caller-saves -fhonour-copts -Wno-error=unused-but-set-variable -msoft-float -mips16 -minterlink-mips16 -std=c99 -MT src/common/address.o -MD -MP -MF $depbase.Tpo -c -o src/common/address.o src/common/address.c &&\ mv -f $depbase.Tpo $depbase.Po src/common/address.c: In function 'tor_addr_lookup': src/common/address.c:250:21: error: storage size of 'hints' isn't known struct addrinfo hints; ^ src/common/address.c:255:5: warning: implicit declaration of function 'getaddrinfo' [-Wimplicit-function-declaration] err = sandbox_getaddrinfo(name, NULL, &hints, &res); ^ src/common/address.c:260:45: error: dereferencing pointer to incomplete type for (res_p = res; res_p; res_p = res_p->ai_next) { ^ src/common/address.c:262:20: error: dereferencing pointer to incomplete type if (res_p->ai_family == AF_INET) { ^ src/common/address.c:265:27: error: dereferencing pointer to incomplete type } else if (res_p->ai_family == AF_INET6 && !best) { ^ src/common/address.c:268:35: error: dereferencing pointer to incomplete type } else if (family == res_p->ai_family) { ^ src/common/address.c:275:15: error: dereferencing pointer to incomplete type if (best->ai_family == AF_INET) { ^ src/common/address.c:276:65: error: dereferencing pointer to incomplete type tor_addr_from_in(addr, ^ src/common/address.c:279:22: error: dereferencing pointer to incomplete type } else if (best->ai_family == AF_INET6) { ^ src/common/address.c:281:55: error: dereferencing pointer to incomplete type &((struct sockaddr_in6*)best->ai_addr)->sin6_addr); ^ src/common/address.c:284:7: warning: implicit declaration of function 'freeaddrinfo' [-Wimplicit-function-declaration] sandbox_freeaddrinfo(res); ^ src/common/address.c:287:20: error: 'EAI_AGAIN' undeclared (first use in this function) return (err == EAI_AGAIN) ? 1 : -1; ^ src/common/address.c:287:20: note: each undeclared identifier is reported only once for each function it appears in src/common/address.c: In function 'tor_addr_parse_PTR_name': src/common/address.c:519:5: warning: implicit declaration of function 'strcasecmp' [-Wimplicit-function-declaration] if (strcasecmp(cp, "ip6.arpa")) ^ src/common/address.c: In function 'ifaddrs_to_smartlist': src/common/address.c:1243:26: error: 'IFF_UP' undeclared (first use in this function) if ((i->ifa_flags & (IFF_UP | IFF_RUNNING)) != (IFF_UP | IFF_RUNNING)) ^ src/common/address.c:1243:35: error: 'IFF_RUNNING' undeclared (first use in this function) if ((i->ifa_flags & (IFF_UP | IFF_RUNNING)) != (IFF_UP | IFF_RUNNING)) ^ src/common/address.c: In function 'ifreq_to_smartlist': src/common/address.c:1404:35: error: dereferencing pointer to incomplete type const struct sockaddr *sa = &r->ifr_addr; ^ src/common/address.c:1414:19: error: dereferencing pointer to incomplete type buf += _SIZEOF_ADDR_IFREQ(*r); ^ src/common/address.c: In function 'get_interface_addresses_ioctl': src/common/address.c:1429:17: error: storage size of 'ifc' isn't known struct ifconf ifc; ^ Makefile:2962: recipe for target 'src/common/address.o' failed make[4]: *** [src/common/address.o] Error 1 -- Lars Boegild Thomsen https://reclaim-your-privacy.com Jabber/XMPP: lth(a)reclaim-your-privacy.com

5 9

Simple Relay Scanner Example
by Damian Johnson 23 May '15

23 May '15

Hi Roger, earlier this week you asked me for a simple bandwidth-authority style scanner. This dovetailed nicely with a task that's been on my todo list for ages to make a tutorial for manual path selection so here ya go! https://stem.torproject.org/tutorials/to_russia_with_love.html#custom-path-… Cheers! -Damian

1 0

Re: [tor-dev] The Onion Name System (OnioNS)
by OnioNS Dev 23 May '15

23 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/20/2015 12:18 AM, tor-dev-request(a)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 explicitly: even with unlimited CPU power, (setting aside the potential for cryptographic breaks) an attacker would not be able to compromise the Quorum and thus OnioNS as a whole. I am assuming that more Tor routers are controlled by honest sysadmins than by adversaries. An adversary could spin up many new Tor routers in an attempt to increases his chances of controlling the Quorum, but he also has to earn the required router flags, which is costly. Anyone who remembers the Lizard Squad incident recalls how quickly Sybil attacks are dealt with. I can theoretically extend the size of the Quorum to the size of the Tor network, so then the attacker has to gain control of the Tor network such that his colluding nodes form the largest group of Tor routers signing the same Page. It's not about CPU power, it's about the honesty of nodes in the Tor network. That gives me the globally collision-free property. Perhaps I have lowered the bar, but I do think it's a bit higher than Namecoin because OnioNS is only dependent on the distribution of identities, and not the distribution of CPU power. > So if this is successfully deployed and massively used, I could see the NSA/FBI/CIA team up, buy up computing and network resources globally for a month (or however long it takes) to take control of _all_ established high-profile hidden service sites. At least that's plausible enough for me. As I said, to break OnioNS they would have to introduce many routers into the Tor network in order to increase their chances of gaining control of the Quorum. You can think of hidden services here like owners in Namecoin; they just control their information, which is orthogonal to the actual functionality of the system. > Could we please make the protocol a bit more general than this? Yes, I will look into it. Your description is helpful, but if you want to write up a protocol describing what you want on your end, I'll merge it into my protocol, and then we'll have a protocol that is compatible with both of our needs. I would be happy to modify my software accordingly. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVYKpIAAoJEK2XNk/CC+yA6osIAKNoLUKNU1b2T6mafePb+Tv+ 9NtZzG88bzqBv077mQE+UVPAuma/dibYocLNdqQo+9NHSxR/E1XWT4RdlxLnkhXN 5iXVjFXSqzXzgAEiVHXCzjMsii+4JBP50Dz5bqOGy2yxiXw4qD5aSMnegpTpJx7W r5gxkf9wOqA72iFECigAPRlRZKvAgZ1C/nFAB1oDQd2fY9n7A159Dky1YmJB+JnC c3f3j50NxvfXnuaBYwKkl956cb7YRSEPqdg8y7pCQ9CEpwZc3AXZY5xZlDNUknJ9 EMY64j0krJLFwPgSaRRnNNdyTXPydrAO6j7i7WcOK2rOnEj6+y3VtswzK27ZAdc= =AcK+ -----END PGP SIGNATURE-----

2 1

shipping with fallbackdir sources
by l.m 22 May '15

22 May '15

Hi, a couple questions about fallback directories. On 4/17/15, Peter Palfrader wrote: > We want them to have been around and using their current key, address, > and port for a while now (120 days), and have been running, a guard, and > a v2 directory mirror for most of that time. In the script (and proposal 206) a candidate for fallback uses the orport. When is the http directory connection used? Is it just for backwards compatibility? Does the directory address being different not matter? A candidate can only be or-address+orport? If the document is signed why is bootstrapping using the or-address+or-port for candidates a key consideration? Aren't the clients going to switch to guards and tunneled dir-connections anyway? (Unless configured otherwise) In a worst-case the client would still use bridges if tor is blocked--and it doesn't look like the fallback-dir are being considered for this case anyway. Is there more documentation somewhere? Thank-you --leeroy

1 0

Quantifying the similarity between Tor relays
by Philipp Winter 22 May '15

22 May '15

It is often helpful to determine the similarity between relay descriptors. For example, to detect Sybil attacks, or to find partners in crime once we found a malicious relay. I recently added code to sybilhunter that can automate this task. Now to the underlying theory. The algorithm makes use of a vantage point tree (vp-tree), which enables O(log n) search for nearest neighbours. We then take a file as input -- for example a consensus document -- and add every relay to the vp-tree. For node comparison, vp-trees require a distance metric in the mathematical sense, i.e., the metric has to satisfy the triangle inequality. For now, I use the Levenshtein distance. It takes as input two strings and returns the number of character edit operations (replace, insert, remove) that are necessary to turn descriptor A into descriptor B. While easy to understand and use, the Levenshtein distance cannot easily incorporate our domain-specific knowledge. I hope to find something more suitable. Before comparing relay descriptor, I preprocess them. For network status documents, I consider nickname, ports, publication time, flags, version, and bandwidth. I believe this is a good start, but there is much room for improvement and feedback is very welcome. Now here's how you can give it a shot. The commands below find the 10 closest relays to the relay we run at Karlstad University: $ go get git.torproject.org/user/phw/sybilhunter.git $ wget https://www.nymity.ch/~phw/sample-consensus -O /tmp/consensus $ sybilhunter -data /tmp/consensus -neighbours 10 -rootrelay 9B94CD0B7B8057EAF21BA7F023B7A1C8CA9CE645 On my laptop, it takes approximately 10 seconds to generate the vp-tree. The output then consists of 10 blocks that represent the most similar relay descriptors. The first two lines of each block show the input to the Levenshtein distance. The third line shows the distance and a link to the relay's Atlas page. Cheers, Philipp

1 0

[PATCH] Defences against the recent hidden service DoS attacks
by George Kadianakis 21 May '15

21 May '15

Hello, we recently received more reports of Denial of Service attacks on hidden services. You can find our ticket here: https://trac.torproject.org/projects/tor/ticket/16052 After some debugging, we found the attack vector and identified a few ways to fix or mitigate it. In this attack, the adversary forces a hidden service to create thousands of connections to its underlying application (e.g. the webserver), which overwhelms both Tor and the underlying application. It's worth noting that Tor is a small network, and even simple DoS attacks can be quite effective against it. Consider that there are botnets out there with more bandwidth than the whole Tor network. Hence, completely solving DoS attacks on Tor is still an open problem; a few long-term defense ideas were stated on the trac ticket. In any case, we have prepared an experimental short-term fix for this vulnerability that hidden service operators can deploy. It seems to mitigate the attack in our lab tests, so maybe it helps others too. The fix, allows the hidden service operator to ignore hidden service circuits that try to open tons of connections. This is possible since normal clients will only open a few such connections, whereas the attacker was opening like 5000 connections per circuit. Here are some instructions for the short-term fix: == Instructions == Our patch is not in an official Tor release yet, so you will need to use an unofficial git branch: https://trac.torproject.org/projects/tor/ticket/16052#comment:18 First, use one of the provided branches or apply the commits directly to your tor, and recompile your tor. You need to do this. The instructions below *won't* work with stock tor. Next, an operator who wants to deploy this experimental fix, should first figure out how many simultaneous TCP connections a normal client would establish. For example, an IRC server would probably not need more than 1 simultaneous connection per user. A web server, depending on the use, might need something between 6 to 12 (?) simultaneous connections. To proceed, as an example, let's say that a client of your hidden service can work fine with 20 simultaneous TCP connections. Then add the following to your torrc, as part of the per-hidden service configuration: HiddenServiceMaxStreams 20 and start up your new Tor. See if that helps out for you. You might still get 100% CPU when under attack, but other clients should work normally. If that doesn't stop the attack, there is a more aggressive solution that might work. In your torrc also add the following line HiddenServiceMaxStreamsCloseCircuit 1 That will make your hidden service *kill* the attacker's circuit, which will reduce CPU load even more. However, if you have picked a small max streams number, it might also kill normal users' connections. So be careful! Also, please don't set max streams to a tiny value while this is enabled; forcing the attacker to build tons of circuits to you is not good for your HS or for the network. ==== In any case, let us know if this works for you, by sending an email to this list, or commenting on the trac ticket. If it works for people, we might incorporate to a Tor release soon.

2 1

Draft of proposal "Direct Onion Services: Fast-but-not-hidden services"
by George Kadianakis 21 May '15

21 May '15

Hello, I inline a proposal for Direct Onion Services. It's heavily based on the "encrypted services" proposal of Roger, but I refined it, made it more proposaley and enabled a few more optimizations. You can find the original piece here: https://gitweb.torproject.org/torspec.git/tree/proposals/ideas/xxx-encrypte… Feedback would be greatly appreciated. Here are some specific points that I would like help with: - Should we require a specially compiled version of Tor to enable this feature? Like we do for tor2web mode? In this proposal, I didn't require any special compilation flags. I don't have strong opinions here. - We really really need a better name for this feature. I decided to go with "Direct Onion Services" which is the one that the NRL people suggested here: https://lists.torproject.org/pipermail/tor-dev/2015-February/008256.html I'm not super happy with it, but I can't think of better ones myself. Here are some candidates: 1 Way Anonymous Hidden Services Fast Onion Service Short-circuited Onion Services Fast-but-not-hidden Services - We also need a better torrc option. If the name of this feature does not portray its dangers, then the torrc option should be a bit terrifying. That's why I went 'DangerousDirectOnionService' which I actually don't like at all. BTW, it's unclear whether this mailing list is the best place to brainstorm for names. Here goes proposal: ---- Filename: 244-direct-services.txt Title: Direct Onion Services: Fast-but-not-hidden services Author: Roger Dingledine, George Kadianakis Created: 2011-01-12 Status: Draft 1. Motivation Hidden services can cover multiple use cases and threat models. They offer server-side anonymity by default because that's the most common use case, but there also hidden service users who don't really need service-side anonymity. This proposal aims to satisfy those users by introducing an optional opt-in feature that *sacrifices server-side anonymity* *for better performance*. Client-side anonymity will still be preserved as normal. Here are some use cases that this idea addresses: 1) Indymedia wants to run an exit enclave that provides end-to-end authentication and encryption. They tried running an exit relay that just exits to themselves (#800) but * it handles lots of other traffic too since it's a relay * exit enclaves don't actually work consistently, because the first connection from the user doesn't realize it should use the exit enclave. 2) Wikileaks uses Tor hidden services not to hide their service, but because the hidden service address provides a type of usability we didn't think much about: unlike a more normal address, a Tor hidden service address either works (meaning you get your end-to-end authentication and encryption) or it fails hard. With a hidden service address there's no way a user could accidentally submit their documents to Wikileaks without using Tor, but with normal Tor it's possible. 3) The Freenode IRC network wants to provide end-to-end encryption and authentication to its users, a) to handle the fact that the IRC protocol doesn't really provide much of that by default, and b) to funnel all their Tor users into a single location so they can handle the anonymous users better. They don't mind the fact that their service is hidden, but they'd rather have better performance for their users given the choice. As a side-effect, by optimizing for performance in this feature, it allows us to lean more heavily towards security decisions for regular onion services. 2. Design We suggest the following changes to be implemented: i. Add a way in the torrc file to specify that this service wants to be an encrypted service rather than a hidden service. [TORRC] ii. An encrypted service SHOULD establish 1-hop circuits to its introduction points. [ONEHOP] iii. An encrypted service SHOULD establish 1-hop circuits to rendezvous points [ONEHOP]. iv. An encrypted service MAY NOT use static guard nodes [NOGUARDS]. More information about these steps can be found in the next section. 3. Specification 3.1. Torrc configuration parameter [TORRC] To enable this optional feature, we introduce the boolean DangerousDirectOnionService torrc option. The option MUST be *disabled by default*. Because of the grave consequences of misconfiguration here, we have prepended the torrc option with 'Dangerous'. Furthermore, Tor MUST issue a startup warning message to operators of the hidden service if this feature is enabled. 3.2. One-hop circuits [ONEHOP] When in this mode, the onion service establishes 1-hop circuits to introduction and rendezvous points. The onion service SHOULD also ignore cannibalizable 3-hop circuits when creating such circuits. This looks like this for the rendezvous point case: |direct onion service| -> RP <- client middle <- client guard <- |client| This change allows greater speeds when establishing a hidden service circuit and reduces round-trip times. As a side-effect, busy onion services with this feature cause less damage to the rest of the network, since their traffic gets passed around less. 3.3. Disable guard nodes [NOGUARDS] Entry guards are a security measure against Sybil attacks. Unfortunately, they also act as the bottleneck of busy hidden services and overload those Tor relays. This proposal suggests disabling the entry guard feature entirely when this mode is enabled. This allows the hidden service to split its traffic out to multiple relays on the network. 4. Security implications There's a possible second-order effect here since both encrypted services and hidden services will have foo.onion addresses and it's not clear based on the address whether the service will be hidden -- if *some* .onion addresses are easy to track down, are we encouraging adversaries to attack all rendezvous points just in case? 5. Future Here are some thoughts on things we could look in the future to further optimize performance when this mode is enabled: - We should look whether we can optimize further the preemptive circuits that Tor makes as a hidden service. - We could also make hidden services determine the number of introduction points based on their popularity, to allow greater load balancing. This has the potential for leaking the popularity of hidden services (#4862), but maybe this is not a concern when this mode is enabled. - For this mode, we could look into alternative designs where a rendezvous step is not needed, and the traffic gets routed through the introduction points (as in Valet nodes [0]). [0]: http://freehaven.net/anonbib/#valet:pet2006

12 26

Namecoin .onion to .bit linking
by Jeremy Rand 21 May '15

21 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Tor-Dev, One of the criticisms of Namecoin which seems to be raised sometimes is that the current domain namespace spec doesn't have a method for a .bit domain owner to prove that they are in control of a .onion. (This is also an issue for .bit domains that point to .i2p.) I'm interested in improving this situation, and am looking for feedback. First off, I'm curious what the various use cases are for this. The main use case I'm aware of is if a user is aware of a .onion domain already, and is trying to find a human-memorable way to access it. (As far as I can tell, the reverse is not a use case, because if you already trust the .bit domain by name but don't know what .onion you're looking for, presumably Namecoin already does what you want.) Is this correct? Am I missing any other significant use cases? Second, I'm looking for feedback on my rough approach. The approach I'm looking at right now is to have a Namecoin namespace for .onion backlinks to .bit domains, which is separate from the Namecoin namespace for .bit domains. The backlink namespace would have a name field whose prefix is the .onion domain. We can't prevent a squatter from registering an exact match of the .onion in Namecoin, but by using a prefix and checking the signature on all matches, we can avoid the impact of squatters. (The cost of obtaining new names would be a deterrent for someone trying to flood a .onion prefix with invalid backlinks as a DoS.) The value field would contain a signature of the domain name being pointed to, signed by the .onion key. The .onion key could also sign revocations of an endorsement of a .bit domain; these would also be in that namespace. Is this generally a good approach? I'm aware that cross-protocol attacks need to be carefully considered when signing things with a .onion key -- do you have suggestions on how I can sign a short JSON string of the rough form {"name": "d/domain", "rev": 0} (which corresponds to endorsing domain.bit, and not being a revocation of that .bit domain) in a way that won't open up attacks on the .onion key's normal protocol usage? I'll write up a more formal spec after feedback is received, just to make sure I'm not missing some important details. Cheers, - -Jeremy Rand https://namecoin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVW0v7AAoJEAHN/EbZ1y06C+AP/3RxO99cPoBQ6eRcY9cefqlC HGnfUtxfAa7Ao2Ea2ZatHjA36ordtz6vo9UpJKDXXLPuQFMnsW/Xf6m2ePCKPssG uivWnAqoZ/zFaJFXf6RqgADrbUei7jW75DFmJfwhPka3kh76mF/B3mMIRx9bCOIq r8XcKRlmbFv55j0srg2Z6SBpq8aMumxGjStjyzsW8L6bVtBvz4DwN5rAZG958Hm3 ji7b6r+v05s4dIbJ6ZAqerOVmy6PA+sAZ0cqwzCBBttdIoVzGiuc9S6aAn8+XjWa ycx7wUi3YM27Kyor8N2+pYDgECmMYEC9QBKN6XwtsW6Lwz9UCNaZ4BQR5JWIxwLg FTZ1uV/E7o3cKdiPzlCkzoQetifom8la6ezPOpr4XhVuzLWqHJBm4eA+qEwEPSFC DA4k/HEgJKNUZGFWuXpIyEAl3Nvyy3cxTYyrzzMmbvBJnzMGM18Sa+D9N78ih3Sw GgXIET336wnvd+HqcVT85io7Ee3Wj+05IOyH4mhV06AXJuP1RvFAKJk6d1i5lOKC Sr2GrJNnP8zP1uq57XQxpKg7fkVqBMzjFY9JJ6HIkffLsGzLpZ8CUSU2+8tPGeDt T3MAT3GKqXCIjIiQy39Ban27ixeJyxzq8dN3T2HvnUNna0M9v3VhxQjeauNzjHTk 9ekMPDGGT7X9TmLOvSXq =WbCd -----END PGP SIGNATURE-----

3 4

Re: [tor-dev] The Onion Name System (OnioNS)
by OnioNS Dev 20 May '15

20 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 05/19/2015 03:20 AM, tor-dev-request(a)lists.torproject.org wrote: > Subject: > Re: [tor-dev] The Onion Name System (OnioNS) > From: > Christian Grothoff <grothoff(a)gnunet.org> > Date: > 05/19/2015 03:24 AM > > To: > tor-dev(a)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 their opinions, not majorities. (see also http://grothoff.org/christian/fps2013wachs.pdf). Thus, you might want to make it clearer in your paper that you 'square' Zooko's triangle under exactly the same conditions as Namecoin: a weaker adversary model / definition of 'secure'. I think you may misunderstand. Computational power (PoW) here has nothing to do with Zooko's Triangle. With Namecoin, the network is assumed to have more CPU power than adversaries and thus they can achieve all three properties. Here, PoW is only used to increase the difficulty of claiming a domain name, and I get the uniqueness property because I assume that Tor routers are generally honest. This is a safe assumption as if Tor routers weren't honest, Tor circuits would not provide privacy and again the whole system breaks and becomes moot. So, I assume that Tor routers follow the rules and reject duplicate domain names, therefore the network as a whole prevents collisions. An attacker could win here by Sybil attack by spinning up many new Tor routers and gaining control of the Quorum by placing the statistics in their favor. My analysis shows that this is extremely unlikely for L_Q >= 127. > All that being said, I'm not at all against this: We should have MANY ways (protocols!) to assign names, some more usable, some more secure, especially as the current dominant method is just broken (DNS). Glad to have your support. I agree that the Internet DNS is broken. It was never designed with security in mind in the first place; there was no need to because originally everyone knew each other. :) > So maybe Tor can plan to incorporate ".tor", ".bit" (namecoin), ".onion" and ".gnu". After all, each solution has interesting advantages and drawbacks. (The problem then only becomes educating the user about those.) Regardless, good luck with ".gnu" and I look forward to the resulting discussions on dnsop (IETF mailinglist), where you really should launch a discussion on this as well. Yawning mentioned this. It's easy enough to create a spec that defines the protocol for handling other pseudo-TLDs. Currently Tor writes "*.tor" to a named pipe, reads "*.onion", and finishes the lookup. It's easy to use that protocol for any alternative DNS. It's outside Tor's scope to care how the *.tor -> *.onion map is accomplished. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVW26lAAoJEK2XNk/CC+yA+1MH/3HNANFFzhCs567B8XkcHu0M VijH8dD6f+ClxuxVFmjKb5c9jlgK5vW9E+LsFiUFbT3vHdjZxh4nH4zNv1FnVIxc RnkNvuhXGYpDCSRFNtvqa1ZPwOj3ENBvB8++wB/M2DM3KN4B6dKXdHNgjfMDNfji L62o23ApQaKOu8vi0wr9VNLTCbji9LS0GerR5G7mUMAUo194WjBGhNwhBQknCeze RACjHnRjfqDWSyszgI7e0xKNK3rGOzQWIPwlScqnl1LEh6tWaxMZDmzN+FHr2QbG C5Sb1fDywKeVCQdBSAjAS++WvzvYNbiFExaJ9ucVWMPMdjrxjDzpHrVM8P/xWaY= =6kyi -----END PGP SIGNATURE-----

2 1

Re: [tor-dev] Namecoin .onion to .bit linking
by OnioNS Dev 19 May '15

19 May '15

-----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-----

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev May 2015