[tor-dev] T Shits for Relay Operators
Hello, Is the tshirt email system currently working? I have been running a relay since December and I haven't seen one. Btw, I did register my relay using tor weather. Thanks! -- Abhiram Chintangal ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] T Shits for Relay Operators
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have received messages from Tor Weather about earning a t-shirt in the past several months to last week. The grab-your-shirt e-mails seem to be send out correctly. On 6/2/15 9:03 PM, Abhiram Chintangal wrote: Hello, Is the tshirt email system currently working? I have been running a relay since December and I haven't seen one. Btw, I did register my relay using tor weather. Thanks! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev - -- Tim Semeijn Babylon Network pgp 0x5B8A4DDF -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBCgAGBQJVbf/oAAoJEIZioqpbik3fisQP/3eVk8oMs4/GFtANK0FtFT+F g5WGm8YhuyDSqB0+9IE6QvYO03ETcDek0sbmAyurCV8Yqxp4SqFJyoqZM5y0leQe h+fYi23zKrB64a6IVucmFJJHR/+8egA5zSuJVnT1FyobTGi92ZMwBpla1zN45WR4 sYT73rjwRSOb5ZKWvt0WVaOao3TOI1RiMD4qQrBnMgeTYpQVXnOZ5QQyP6UDmFec a4wuql5GpxcDjFYj/Jjbepk8F0EccjMIYdQDUdIch6id4PjlnwH9Z6IkXCocfAsT 0RpRzAQpCt6Fi+3/rFk6M4U+5W0k5QKAFdgw5c71QLsPW7LiNin/xTlAKh8mI0vx 5RUGiSq4I+PCoZuxvdcjrc9m7GsC2hIcm/QsN2q8VY11s+9jNISm0I/JkZVzDuQX rkRo+6EMscQIYVuQci0Ot6+oGyLdH4c1QovypAF7kQNV7HxaEH8uAJBMMP3WkRXC V5BJEixK5b1quRYpavR1ZoDQn5nv7Gp/Enbyv9LBlw25NvAGK4pNTOHDpz11d2Pw /nOsj21vicySShCN2SQdiieVji2GLF5pkv2wyf6z7yIe+L9rTS7JxZhM3/sCwoGp Fb/nTK2s++28V91pbWiKJF2aJVTJ7wKClDnuYiOTDR0nA0KEV/jcWV59+D2Uf0sC gfjr5TcXemF6B1O83me9 =1nlo -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] OS X OpenSSL/Tor Build Instructions
As noted recently, OS X comes with OpenSSL 0.9.8 by default, which is too old to build Tor. During the Tor patch workshop today, rl1987 and Yawning were testing the OpenSSL and Tor builds on OS X. I've put the OS X build steps they used on the Tor Wiki, along with the alternative method of obtaining OpenSSL and/or Tor via MacPorts: https://trac.torproject.org/projects/tor/wiki/doc/MacBuild If you're building Tor on OS X, please try these instructions, fix any mistakes, and add missing steps or other alternatives. In particular, HomeBrew instructions for OpenSSL and Tor would be really helpful for some users. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] onionoo: bug in family set detection?
Date: Tue, 02 Jun 2015 16:52:00 + From: nusenu nus...@openmailbox.org teor: MyFamily requires bidirectional declarations to be effective. I'm aware of that fact ;) In this case: OnionOO appears to correctly implement the bidirectional MyFamily logic Apparently it doesn't. Since onionoo says there is a bidirectional connection (family) between 5510FC1736B16D46D3F2DDA5011995C478D42594 = 0C77421C890D16B6D201283A2244F43DF5BC89DD but there is none.. (as explained in my last email) Compass does *not* say that there is a bidirectional connection between those relays.. onionoo says there is one even though I can't see it, do you see it? I'm sorry, I must have got the onionoo and Compass results mixed up somehow. In Compass, I see that: 5510FC1736B16D46D3F2DDA5011995C478D42594 has no family. In Globe/Atlas (based on onionoo), I see that: 5510FC1736B16D46D3F2DDA5011995C478D42594 has a very large family. So my criticism of Compass actually applies to onionoo. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo: bug in family set detection?
Hello, DirAuth's can cache multiple versions of the descriptor and serve what appears to be the newest in a given consensus interval. This coupled with routers publishing descriptors at least every 18 hours, but potentially sooner. What you describe doesn't appear to be a bug in Onionoo because a consensus exists for which the family is declared as you describe in the last known good descriptor. At the moment you describe Atlas doesn't show: [1] last published 2015-06-02 17:44:27 (and [2] may still have entered hibernate) [2] last published 2015-06-02 09:40:45 (and [1] may not be running, or have a last known good descriptor at DirAuths) This doesn't take into account the possibility of a router hibernating (info not always available) at times between consensus taken or valid. A router can be running but unavailable due to accounting. This looks like a result of cached descriptors or router accounting. The data provided to Onionoo from metrics-lib appears accurate as far as network status. At least that's how it looks from a preliminary glance at the data and spec--although please do your own verification. --leeroy ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo: bug in family set detection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 https://trac.torproject.org/projects/tor/ticket/16276 -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVbiccAAoJEFv7XvVCELh0/rUP/i7Q/cZwYaklkvHAaqmsDffK x8J77/21/5ppN1kyPd8jI7M8ktOC+1uqhV4mlf5CyidKR+2kAhhPYjfX57xQ1sbv OJwDq33EbQiTk/ed3DLQdQpbrt7fqaAzZi3+q2NIKMx2/GFRs6Sxnp7D9b69TEt3 WgW2sEuAuexl//HU01dKxPXp6+5EiW6UBz0eUJcTz4WUf/+CltRBg4sbBXImls3w J5mLqMNwyrRT/StTZB5oSMHsOfxQGgGGJppT0l91onQLzpM1A38ZtgN2zs5tD6T9 OSl7hwhUJHaWR3mg9vDywXO0CQ8tTadfZLGtDU0q5H88vU00jTRW1XA7bKLxtLqY INu9APIjnOhaatVTRGhJMMvP/Vuk6OE/L9n2FBw5FAPxmJ3Tn0+NwElamYizq7o8 AMNpWcfjHxAiH7R9PEuhwYyNktlBz3Swm4uNFvSGPaJsm99lxJLmd7ko9qrxd5Cm WcmQvPpfXN9Ym5iTWlMpu17MLmBGb2YgshFv+fTViCY1JwaEqAlTP+5/m2XmnM2x 8CZgNHjL1C7QWffx6AQYqcoAP183ClR3MD9poan7LMYfaqxXIbLceCzMOKeu9Ptt KPAdPAvACngB9kz43oQeJanE/nmjW90j/hr5oPezL57ayJEvpRiT+cmkkRTT2RvB Aj2Q3IqrXhOzTJkR+N94 =pTF3 -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] Quick logjam/Tor analysis.
Date: Tue, 26 May 2015 09:25:22 -0400 From: Nick Mathewson ni...@torproject.org I posted this on a blog comment, but others may be interested too. As near as I can tell, the logjam/weakdh attacks should not affect current Tor software very much, for a few reasons: * All currently supported Tor versions, when built with OpenSSL 1.0 or later, prefer 256-bit elliptic-curve Diffie Hellman for their TLS connections, not the 1024-bit Diffie Hellman over Z_p as discussed in this paper. … Recommendations: … * If you're running OpenSSL 0.9.8 or earlier, you should consider upgrading to 1.0.0 or later. (Mac) OS X Yosemite 10.10 and earlier ship with OpenSSL 0.9.8 and 0.9.7. For Yosemite 10.10.3 (14D136) in particular, these are: $ ls -l /usr/lib/libssl.* -rwxr-xr-x 1 root wheel 400608 10 Sep 2014 /usr/lib/libssl.0.9.7.dylib -rwxr-xr-x 1 root wheel 616512 20 Mar 13:16 /usr/lib/libssl.0.9.8.dylib lrwxr-xr-x 1 root wheel 18 28 Jan 23:16 /usr/lib/libssl.dylib - libssl.0.9.8.dylib $ strings /usr/lib/libssl.0.9.8.dylib | grep OpenSSL 0.9.8 OpenSSL 0.9.8zd 8 Jan 2015 … $ strings /usr/lib/libssl.0.9.7.dylib | grep OpenSSL 0.9.7 … OpenSSL 0.9.7l 28 Sep 2006 … (As an aside, please avoid running strings on any untrusted binaries.) While it's possible to build or install OpenSSL 1.0 or 1.1 on OS X, it's not the default. How does this affect Tor and/or Tor Browser on OS X? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Adding a NotDir router status flag
Date: Fri, 29 May 2015 14:24:33 +0300 From: s7r s...@sky-ip.org Signed PGP part Hi Matt, Nice to hear there's ongoing work for this proposal. I also see the NotDir flag as useful for migration, because for quite some time after prop 237 is implemented we will still have relays in the consensus which will have DirPort open (separate from ORPort). A client needs to know to make directory requests on DirPort for the relays with V2Dir flag, and know to make directory requests on ORPort for the relays which only have ORPort open and NotDir flag. After (hopefully) medium time we can drop the V2Dir flag (we are way passed from V2 directory anyway) and after longer time we can also drop NotDir. I guess this depends if directory requests on ORPort will be only implemented in new Tor releases or also backport? It's unlikely we'd backport a feature of this magnitude - we already ran into issues (mainly with hidden services) when the authorities assumed that relays with only an ORPort would answer directory requests, but the relays weren't actually doing so. I guess we can say it's safe to drop both flags when over 95% of the relays respond to directory requests on ORPort. We will just need Valid flag to make sure we can separate the relays which try to poison directory data. When relays have AccountingMax set, they disable their DirPort to maximise the bandwidth used for relaying Tor cells. This implies that they should also ask for the NotDir flag, and refuse to respond to directory requests on both the DirPort and ORPort. (We don't want relays that are already bandwidth-constrained receiving directory requests that we know they'll refuse - this is a waste of their bandwidth.) Does this need to be part of prop 237? Since the NotDir flag is still useful in with AccountingMax, we should reconsider the plan to drop NotDir in a few releases' time. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Quick logjam/Tor analysis.
On Wed, 3 Jun 2015 00:43:50 +1000 teor teor2...@gmail.com wrote: (Mac) OS X Yosemite 10.10 and earlier ship with OpenSSL 0.9.8 and 0.9.7. [snip] While it's possible to build or install OpenSSL 1.0 or 1.1 on OS X, it's not the default. How does this affect Tor and/or Tor Browser on OS X? Tor Browser builds/includes it's own copy of OpenSSL, so there is no impact there. As of a little while ago on master, tor requires OpenSSL 1.0.0 with ECDH support at build time. AFAIK this breaks the build with OSX, FreeBSD 9.x, and certain (Old) versions of Centos/RHEL when compiling against the vendor's OpenSSL. The only resolution is Too bad, so sad, install a modern OpenSSL. See #16034 and #16040 for details. -- Yawning Angel pgp01DoAVjA4U.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo: bug in family set detection?
Date: Mon, 01 Jun 2015 19:20:32 + From: nusenu nus...@openmailbox.org Hi, by comparing different methodologies of parsing myfamily data I stumbled upon differences between onionoo and compass. After manual review I assume there is a bug in onionoo (or onionoo has a different opinion on what families actually are) Example: According to onionoo, torpidsDEevanzo [1] is part of a family with 38 members. It lists torpidsFRonline [2] as one of its members, that implies that torpidsFRonline lists torpidsDEevanzo as one of its members as well, but torpidsDEevanzo does _not_ list torpidsFRonline (according to onionoo data). grep 'fingerprint:0C77421C890D16B6D201283A2' details.json|grep 5510FC1736B16D46D3F2DDA5011995C478D42594 (no result) Is this a bug? thanks [1] https://atlas.torproject.org/#details/5510FC1736B16D46D3F2DDA5011995C478D42594 [2] https://atlas.torproject.org/#details/0C77421C890D16B6D201283A2244F43DF5BC89DD No, it's a feature :-) MyFamily requires bidirectional declarations to be effective. This prevents a malicious relay nominating significant portions of the Tor network as its family, in order to direct traffic to another malicious relay. (And/or slowing down the network and attempting to cause a DoS.) In this case: torpids relays have inconsistent MyFamily configurations. OnionOO appears to correctly implement the bidirectional MyFamily logic, and remove inconsistent one-way MyFamily declarations. Compass appears to believe each relay's MyFamily claims, without checking the other relay. This appears to be a fairly harmless bug in Compass, as Compass itself is not used for path selection. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Proposal 245: Deprecating and removing the TAP circuit extension protocol
Filename: 245-tap-out.txt Title: Deprecating and removing the TAP circuit extension protocol Author: Nick Mathewson Created: 2015-06-02 Status: Draft 0. Introduction This proposal describes a series of steps necessary for deprecating TAP without breaking functionality. TAP is the original protocol for one-way authenticated key negotiation used by Tor. Before Tor version 0.2.4, it was the only supported protocol. Its key length is unpleasantly short, however, and it had some design warts. Moreover, it had no name, until Ian Goldberg wrote a paper about the design warts. Why deprecate and remove it? Because ntor is better in basically every way. It's actually got a proper security proof, the key strength seems to be 20th-century secure, and so on. Meanwhile, TAP is lingering as a zombie, taking up space in descriptors and microdescriptors. 1. TAP is still in (limited) use today for hidden service hops. The original hidden service protocol only describes a way to tell clients and servers about an introduction point's or a rendezvous point's TAP onion key. We can do a bit better (see section 4), but we can't break TAP completely until current clients and hidden services are obsolete. 2. The step-by-step process. Step 1. Adjust the parsing algorithm for descriptors and microdescriptors on servers so that it accepts MDs without a TAP key. See section 3 below. Target: 0.2.7. Step 1b. Optionally, when connecting to a known IP/RP, extend by ntor. (See section 4 below.) Step 2. Wait until proposal 224 is implemented. (Clients and hidden services implementing 224 won't need TAP for anything.) Step 3. Begin throttling TAP answers even more aggressively at relays. Target: prop224 is stable. Step 4. Wait until all versions of Tor without prop224 support are obsolete/deprecated. Step 5. Stop generating TAP keys; stop answering TAP requests; stop advertising TAP keys in descriptors; stop including them in microdescriptors. Target: prop224 has been stable for 12-18 months, and 0.2.7 has been stable for 2-3 years. 3. Accepting descriptors without TAP keys. (Step 1) Our microdescriptor parsing code uses the string onion-key at the start of the line to identify the boundary between microdescriptors, so we can't remove it entirely. Instead, we will make the body optional. We will make the following changes to dir-spec: - In router descriptors, make the onion-key field at most once instead of exactly once. - In microdescriptors, make the body of onion-key optional. Until Step 4, authorities MUST still reject any descriptor without a TAP key. If we do step 1 before proposal 224 is implemented, we'll need to make sure that we never choose a relay without a TAP key as an introduction point or a rendezvous point. 4. Avoiding TAP earlier for HS usage (Step 1b) We could begin to move more circuits off TAP now by adjusting our behavior for extending circuits to Introduction Points and Rendezvous Points. The new rule would be: If you've been told to extend to an IP/RP, and you know a directory entry for that relay (matching by identity), you extend using the node_t you have instead. This would improve cryptographic security a bit, at the expense of making it possible to probe for whether a given hidden service has an up-to-date consensus or not, and learn whether each client has an up-to-date consensus or not. We need to figure out whether that enables an attack. (For reference, the functions to patch would be rend_client_get_random_intro_impl and find_rp_for_intro.) ___ 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)
Date: Mon, 18 May 2015 15:48:50 -0800 From: OnioNS Dev kernelc...@riseup.net ... 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. 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?) 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. 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. 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. The HS is down, and has been for some days. For those having trouble accessing the paper through the direct link, try clicking on acm-ccs.pdf on: https://github.com/Jesse-V/Thesis/tree/master/conference I got a format error from GitHub when I tried the direct link in Tor Browser 4.5. … 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. 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. 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? teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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)
On 3 Jun 2015, at 02:07 , teor teor2...@gmail.com wrote: Date: Mon, 18 May 2015 15:48:50 -0800 From: OnioNS Dev kernelc...@riseup.net ... 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. 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?) 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. Some day, I will learn to read the whole paper before opening my mouth. I apologise - I withdraw my questions in the face of thousands of bits of entropy per hour, and a comprehensive security analysis. 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. In an earlier section, Alice is a Tor client. This makes this section make sense. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7 signature.asc Description: Message signed with OpenPGP using GPGMail ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] onionoo: bug in family set detection?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 teor: MyFamily requires bidirectional declarations to be effective. I'm aware of that fact ;) In this case: OnionOO appears to correctly implement the bidirectional MyFamily logic Apparently it doesn't. Since onionoo says there is a bidirectional connection (family) between 5510FC1736B16D46D3F2DDA5011995C478D42594 = 0C77421C890D16B6D201283A2244F43DF5BC89DD but there is none.. (as explained in my last email) Compass does *not* say that there is a bidirectional connection between those relays.. onionoo says there is one even though I can't see it, do you see it? -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVbd8wAAoJEFv7XvVCELh0clQP/AoZmVBLltEWueM0OYH52IS0 1ZLGjhhnCd/PhEUOrgr0Y4Q4/My7IzCNVSMwca9FPBiFKLIg4ejQf+vTTVkCJFD8 aw+gJImqKTD2x7WP5V36kjIDJjnWpDsybcx/kjEGA8j3yeIx67MdySc3daRl5c9e sk5rl1HlhR2LFyFzNNc+pq08plJxDU8ciW5vaMLDUotumkenkF8DBaYonqlAE/bk etyBdphZWvCVW9WrwkMoeYZZEgDt0WlS1iKjUb6kuHGYIlmx6/4tCBHglW85hDB3 AsKxKRohoxZEwG6QGiTAC+zbYeMT3Gzgs549Tja4WDkYieZrrfNCCaOj2SRa1aaQ DCz4u9LQFRtr4oHqLA0JlHedEHziRogOt25CdQCch7Bu33P5Gsj9wpYEICmpWNPS hyLPTQTZMWb21PUuJ33VUWSZ//fLF5zJkkJiO+rp+OBt205n6+8PjY9vRAXu00QU 5qsIwwjklpnt2i4EFKOgSPkFczgRaW7ZyPdu7NRbfrD8VMYeeSWjlAJ2JZc7kKkp q4UWPysTULTbltMOqE8+SRy1m8G2HU1wsSDY95ajhqVjikPSw+ROx2LKPPYr/OzC KrDKxqOzwX032GY0fRSLNLz3grMP+MdZtHC47qb2Ki+1d99Ifw+F7XCHeIXVrWKv XqGLL2yYZjfZyTaPn25w =mDOq -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
