- tor-dev - lists.torproject.org

Re: [tor-dev] Hash Visualizations to Protect Against Onion Phishing
by Jesse V 21 Aug '15

21 Aug '15

> Jacek Wielemborek <d33tah(a)gmail.com> writes: > >> George Kadianakis pisze: >>> Some real UX research needs to be done here, before we decide something terrible. >> >> Just curious, has anybody seen any cognitive studies on the SSH >> randomart visualisation? I always found them impossible to remember. >> Perhaps adding a bit more color could help... > Hm. Indeed. > > I can remember the general shape and edges of my SSH server's key, but not any > details. > > I doubt I would remember the randomart of like 10 onion websites, especially if > I didn't visit them regularly. But maybe I would remember the randomart of my > webmail better than my SSH server's. > The main issue is that there's always going to be a tradeoff between memorability and security. It's difficult to cram sufficient entropy into a visualization and expect people to remember it. I agree that coloring schemes or perhaps faces stand the best chance of memorability, but they are difficult to deploy. I wonder if a simpler scheme is sufficient. I suggest using a word-bank to generate a series of words. First, take the .onion address or the hidden service public identity key (basically the same thing for 224) and run it through scrypt or similar algorithm. Then, based on the output, select a series of words from the dictionary. Present the series of words in George's mockup (https://people.torproject.org/~asn/tbb_randomart/randomart_mockup.png) in lieu of the art. It's not a new idea to use a word-list for this purpose: I recall reading a paper suggesting to use a word-list to encode .onion addresses rather than base32. The scheme has also been deployed by websites; Gfycat, for example, shows a series of words in its URL to provide an identifier to user images. It's also successful in practice: everyone in the /r/globaloffensive subreddit recognizes the DelayedAutisticGuppy reference before they even open the gif. People remember random information best if it's grouped, but usually the maximum group size is about 4, which is why phone numbers are split with delimiters. To make it simple, I suggest showing one row of four words. Each character in a .onion address has 32 possible combinations. If you used a word-bank of 1,024 words, you cover two characters per word. If your dictionary consists of 32,768 words, you can capture three at a time. Assuming this latter case, if four words are used, you can cover 12 characters, or 60 bits. If you combine that with the number of characters in the address that users intrinsically check subconsciously, it's extremely difficult for an attacker to match all of them. The Shallot README indicates that it would take nearly 10 millenia to find a 12-character match, and this of course does not take into account a round of scrypt before the word-list is used. Everyone remembers "correct horse battery staple", right?

4 3

6th status report for OnioNS
by Jesse V 20 Aug '15

20 Aug '15

This status report covers three main points of progress for the Onion Name System (OnioNS) project. 1) Since my last report, I opened up this project for beta testing. The server logs show that a number of people opened and ran servers for some time, and a number of individuals claimed names for their hidden services. S7r was extremely helpful in beta testing, we had a very productive private conversation on IRC. He helped me identify bugs and several areas of improvement. He also reproduced a few show-stopping issues that I had considered closed, so I'll be taking care of those as soon as I can. It was a thorough test and I very much appreciate the help. 2) I spent a significant amount of time over the last few weeks rewriting my design paper. I applied two suggestions that I heard during PETS and the Arlington HS meeting: a) to switch from using the consensus for a global source of entropy to the new commit-and-reveal proposal, and b) to select members of the Quorum (the authoritative set of OnioNS nodes) with selection weight proportional to their consensus weight, rather than with even probability. Both of these turned out to be excellent ideas. The dirauth commitment protocol is far more resistant to attacks than my original scheme and the new Quorum selection technique is highly resistant to Sybil attacks. In fact, even if all Fast and Stable routers in the lowest 70 percentile by consensus weight are malicious, it's still extremely unlikely that a random Quorum selection will result in a situation where the attacker wins. 3) There's an upstream change that I forgot to mention in my last report: the fact that Tor 0.2.7 now creates and manages Ed25519 keys brings OnioNS one step closer towards integration with Tor: my design documents call for OnioNS servers to manage Ed25519 signatures. It's a stronger and faster cryptosystem than RSA and has much smaller signatures, which reduces the overhead of my data structures. Down the road, I should be able to use the online signing key, so I won't need to touch the offline identity key. As we come closer to the end of the Summer of Privacy timeline, I'm going to concentrate on addressing the bugs that s7r identified, finish implementing some security protocol, and try to move to a fully decentralized setup. Jesse V.

1 0

bwauths: Are you publishing your output somewhere?
by nusenu 19 Aug '15

19 Aug '15

Hi, since a request to make bwauth output available has been closed as wontfix previously [1] I'm not going to ask whether this data would be added to CollecTor, but maybe bwauth ops are publishing it 'inofficially' (like Tom does [2]) for the dir auth to fetch already and would be willing to disclose the URI to the files? thanks! (one can also use the votes [3] to find out what the dir auth submitted but the raw bwauth files would include the timestamps/frequency) [1] https://trac.torproject.org/projects/tor/ticket/2532 [2] https://bwauth.ritter.vg/bwauth/ [3] https://collector.torproject.org/recent/relay-descriptors/votes/

1 0

[Measurement Team] Next IRC meeting happens on Wednesday, Aug 19, 14:00 UTC in #tor-project
by Karsten Loesing 18 Aug '15

18 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello list, This is an announcement/reminder that there will be an IRC meeting of the Measurement Team on Wednesday, August 19, 2015, 14:00 UTC in #tor-project https://www.timeanddate.com/worldclock/fixedtime.html?iso=20150819T14 Suggested agenda is quite similar to last week which worked pretty well: - 1-1-1 task exchange: you get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do for you within 1 week (review a document, write some analysis code, fix a small bug, etc.; better come prepared to get the most out of this; give 1, take 1) - Misc/discussion: whatever comes up during the meeting If you think this can be fun, please join us at the meeting! Talk to you tomorrow! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJV0zycAAoJEJD5dJfVqbCrwS4H/2YWIf9LxzQJMgmfD//Stqr2 6Set5ZYzMnzNgSgiOY1edaza0tepG+oDPOCaaM2ly7+2HAH9HmjoGb6qBRl6Y8Of XdhXp5jgGLrHeee1oznNWsrgY8K/I1Oh26Q6IlPsTyNEVbxL3IvHMX/nz0q7QXUT iL1UkzwldU6wVVnn8E1Y6HgQlRnipsC1ii0VXEnSp+O4JQ0fXU0l88ZsEywff6fo iSyYzLFT1YUcoFfHRALyCwLKrIDCWjWDlP3Zi7C3BZD2uWyJTqL1FExnoAXlBkTq ruCt+nJWNFsF4QFxhQqxOfeGLGPja4Lap1BTqYRjXe8pMZ4ZPZoah+0ht7okCr4= =/tK9 -----END PGP SIGNATURE-----

1 0

Re: [tor-dev] Get Stem and zoossh to talk to each other
by tordev123＠Safe-mail.net 17 Aug '15

17 Aug '15

> > zoossh's test framework says that it takes 36364357 nanoseconds to > > lazily parse a consensus that is cached in memory (to eliminate the I/O > > bottleneck). That amounts to approximately 27 consensuses a second. > > > > I used the following simple Python script to get a similar number for > > [...] > > This script manages to parse 24 consensus files in ~13 seconds, which > > amounts to 1.8 consensuses a second. Let me know if there's a more > > efficient way to do this in Stem. > > Interesting! First thought is 'wonder if zoossh is even reading the > file content'. Couple quick things to try are... > > with open(file_name) as consensus_file: > consensus_file.read() > > ... to see how much time is disk IO verses parsing. Second is to try > doing something practical (say, count the number of relays with the > exit flag). Stem does some bytes => unicode normalization which might > account for some difference but other than that I'm at a loss for what > would be taking the time. Why are you surprised? Python is a very, very slow language. My very simple unoptimized C++ parsing code is more than 10x faster than Stem (parsing from memory). Go has some nice string parsing features, so zoossh should have an easy time to get fast and simple parsing code.

2 1

Get Stem and zoossh to talk to each other
by Philipp Winter 17 Aug '15

17 Aug '15

Hi Damian, I'm interested in building a lightweight, internal domain-specific language to explore archived Tor data. The goal is to make it easy to answer questions like the one that recently came up on tor-relays, "how many guards shift location significantly across the Internet, and how often?" Combining Stem and zoossh seems like a good solution. Ideally, zoossh should do the heavy lifting as it's implemented in a compiled language. For data exploration, however, having a Stem-enabled Python shell with a set of analysis methods sounds better. Now the question is how to pass potentially large amounts of readily-parsed consensuses and descriptors from zoossh to Stem? In a perfect world, we would have bindings to use zoossh in Python. The gopy [0] folks are working on that, but it's a young project; interfaces are not yet supported. Two workarounds come to mind until gopy catches up, both requiring some glue code: 1. Let zoossh do the data filtering and then return a list of files that are then parsed again by Stem. That's easy to implement, but can be quite inefficient if the filtering step still returns plenty of data. 2. Have some IPC mechanism that passes objects from zoossh to Stem. Objects could be serialised in some way to minimise unnecessary parsing. While that might be the most efficient option for now, it probably requires too much work. 3. ...something else I didn't consider? Please let me know if you have any thoughts. [0] <https://github.com/go-python/gopy> Cheers, Philipp

3 10

Alpha/Beta/Release cycle
by tordev123＠Safe-mail.net 14 Aug '15

14 Aug '15

TBB 5.0 Bug 16771 which seems to be causing a lot of crashes was apparently introduced with commit 77dcb2dfde4bdc1a2f6c399a1173f65908dccd5c on 2015-07-02 (new request isolation feature). The first release including that commit was apparently TBB 5.0a4 announced 2015-08-03. So there was only 1 week before the stable TBB 5 release and the commit got very little testing. IMHO, it would make sense to make more alpha releases and/or increase the time before the stable release.

1 0

Future Onion Addresses and Human Factors
by Alec Muffett 13 Aug '15

13 Aug '15

Hi All, Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion moved to Onion-Address Human Factors. Summary points: 1) it’s all very well to go an mine something like “facebookcorewwwi” as an onion address, but 16 characters probably already exceeds human ability for easy string comparison. 2) example of the above: there are already “in the field” a bunch of onion addresses “passing themselves off” as other onion addresses by means of common prefixes. 3) next generation onion addresses will only make this worse 4) from Proposal 244, the next generation addresses will probably be about this long: a1uik0w1gmfq3i5ievxdm9ceu27e88g6o7pe0rffdw9jmntwkdsd.onion 5) taking a cue from World War Two cryptography, breaking this into banks of five characters which provide the eyeball a point upon which to rest, might help: a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sd.onion 6) using underscores would be a pain (tendency to have to use SHIFT to type) 7) using dots would pollute subdomains, and colons would cause parser confusion with port numbers in URIs 8) being inconsistent (meaning: “we extract the second label and expunge anything which is not a base32 character”, ie: that with-hyphens and without-hyphens) may help or hinder, we’re not really sure; it would permit mining addresses like: agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion # illustration purposes only …which *looks* great, but might encourage people to skimp on comparing [large chunks of] the whole thing and thereby enable point (2) style passing-off. 9) appending a credit-card-like “you typed this properly” extra few characters checksum over the length might be helpful (10..15 bits?) - ideally this might help round-up the count of characters to a full field, eg: XXX in this? a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion 10) it might be good to discuss this now, rather than later? Hence this email, in the hope of kicking off a discussion between people who care about human factors. :-) - alec — Alec Muffett Security Infrastructure Facebook Engineering London

11 27

tor's definition of 'median'
by nusenu 13 Aug '15

13 Aug '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2028 > If 3 or more authorities provide a Measured= keyword for a router, > the authorities produce a consensus containing a "w" Bandwidth= > keyword equal to the median of the Measured= votes. a random sample from recent votes: grep 37.59.38.117 -A 3 *|grep Measured w Bandwidth=6869 Measured=7570 w Bandwidth=6869 Measured=15500 w Bandwidth=6869 Measured=18100 w Bandwidth=6869 Measured=30500 Tor says the median value is 15500 2015-08-10-16-00-00-consensus: w Bandwidth=15500 but the median of these 4 values is actually: (18100+15500)/2 = 16800 no? Has tor a different definition of 'median' and simply takes always the second ordered measurement vote out of 4 votes or is there a bug in the spec or implementation? -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVyNtYAAoJEFv7XvVCELh0YU8P/0hWhCLfafvFDPdAfUwUJFPA A1ZA946JGKg1Vjy+ch3tffjDHRosXt7K5U33N9rKMUlW9ul2BQ+uNgzK4eTbghHz yCMn6D+uLk1xruYTsIUZ+Pk/ZywaUKj/FngohVvQnaJIgJCHCEnCIqqBNEK0PjUh EBzI5GdyWpEA2fh55PSRuSNCVzbiVhGwYSKgrVwFrFcKr9iPLmdZsa9SD1mb1PD1 IZOkU6TnSnFGbPaN+pHYdNr5/QJA1/08yYBpG7qAJaTCAMvMif7bKMJ7ElYo7opc oXcECIcBBPnATgKvbO47dbSnX3s+vPMsrRhhdTa1BMr1MIzVG3RWGhNSJwXXQTJh jyaPGj10JRWNxDsY0ro001MX0HymmXeLLCkY4nWsUqPXDiZcQe4oRzLQas5bOI94 ct4tCavj9pRNp2XYCWe631gqcsQ3xV7y37dWUCvpdXqt2NC1B7j2w/Y/UiuNArSj QBtS4Ap5wqnU5JySjndi+lIPOlaPk9uitmzpKLxNF9fnpI6ZECP3T50vHVeZiiQ9 7o1ZyBsPLk3bi2hRy8ZJ0wyO+5WF8bdrlsKXSR40UjrwQZ5kCQf6xmWiSg9PqZFU rIL14yCOsQkR3P4/IgMlL8dtgFk3Asmkkx039144fRKveEhffFjo54CUMhg/jLra EF5cUqz4QdgcpRvKa/5h =lA/6 -----END PGP SIGNATURE-----

8 12

Re: [tor-dev] [Twisted-Python] please can haz code review -> Tor-ified Twisted Python HTTP proxy server - txtorhttpproxy
by David Stainton 13 Aug '15

13 Aug '15

Dear Aaon Gallagher, Thanks for the helpful observation. i'm going to make the correction soon and then we'll be underscore free. On Wed, Aug 12, 2015 at 7:06 AM, Aaron Gallagher <_(a)habnab.it> wrote: > David Stainton <dstainton415(a)gmail.com> writes: > >> If I get rid of this last terrible import: >> from twisted.web._newclient import ResponseDone >> >> then I'm not sure how to detect when to call the finish() method here: >> https://github.com/david415/txtorhttpproxy/blob/master/txtorhttpproxy/proxy… > > Fortunately, ResponseDone is re-exported by twisted.web.client: > > >>> import twisted.web.client > >>> twisted.web.client.ResponseDone is twisted.web._newclient.ResponseDone > True > >>> twisted.__version__ > '11.0.0' > > I couldn't get 9.0 to compile in the five seconds I tried, but 11.0 is > still pretty old. I think it always was re-exported like this.

1 0