[tor-dev] First release of OnioNS for beta testing
Happy Saturday everyone, At long last, 310 commits later, I am pleased to present a release of the Onion Name System (OnioNS), a DNS for Tor hidden services. This release is a usability test; it offers reliable behind-the-scenes integration with the Tor Browser, a friendly command-line dialog for claiming domain names and subdomains, and many options for hosting and configuring a server. The system utilizes two servers: a single Quorum node which hidden services upload their claims to and another server which clients query against. I am looking for feedback as to how usable the system is and areas where it could be improved. Most of the changes going forward will be behind-the-scenes. The software is divided into three primary pieces, OnioNS-client, OnioNS-HS, and OnioNS-server. These all have OnioNS-common (a shared library) as a dependency. You can install whichever one you'd like, or all of them. This software is currently Linux-only, and Debian 7 and 8, Ubuntu 14.04 - 15.10, Mint 17 - 17.2, and Fedora 21 - 23 are supported. I provide packages for Debian 7 and a software repository for currently-supported versions of Ubuntu and Mint on 32-bit, 62-bit, and ARM systems. If possible, please use the repository. Please see the READMEs in the following repositories for more information, including installation, initialization, and configuration procedures. Manpages are also included for your convenience. https://github.com/Jesse-V/OnioNS-common https://github.com/Jesse-V/OnioNS-client https://github.com/Jesse-V/OnioNS-HS https://github.com/Jesse-V/OnioNS-server Please star the repository if it works well for you. I have claimed example.tor for my project's HS and claimed the arma.example.tor subdomain that points to Roger's site, so you can test this from the client. Please open a ticket if you find a new bug, or contact me if you don't have a Github account. A brief FAQ: Q: How does one pronounce OnioNS? A: As one would pronounce the lowercase form: onions, the plural of onion. Q: It only takes a couple of minutes to claim a domain name, isn't that too easy? A: In this release, I have set a very small difficulty level. It will certainly be harder in the future and more counter-measures are being considered. Also, since the claims are not yet saved to disk, I offer no guarantee of their long-term survival. Q: Should I use this on production hidden services? A: No, this software is not ready. This release introduces _features_, not security. Tor circuits are used on both the client and HS side, but I can't guarantee that my SOCKS use is leak-proof, for example. I'm asking for help with finding bugs that may compromise anonymity. Q: I'm running Windows/OSX/BSD/Arch/Gentoo/LFS/etc, can I test OnioNS? A: Yes, but I'm not currently supporting that environment, so you're mostly on your own. However, if you can give me compilation instructions, I may be able to. I am also looking to coordinate with anyone familiar with RPM or Windows development. Q: Is there security on your network communications? A: Client and HS communication occurs over Tor circuits, and there are some integrity checks, but simply getting everything to work is the priority here. Most of the infrastructure is set up so adding signatures and such will be easy, but that is next on the list. Once that occurs, the name server (Mirror) the client uses can be malicious with no significant impact. Q: Where can I learn more about this project? A: The normal project page, onions55e7yam27n.onion, is currently being rewritten. A simple page is in its place, so example.tor is still there. Literature on this project may be found at https://github.com/Jesse-V/OnioNS-literature. Please see the PDFs under the respective folders. Note that the distributed design will be changing to use George's commit-and-reveal scheme. Q: Are the servers reliable enough to run under Comcast? A: I have not tested them in production or otherwise under https://github.com/tylertreat/comcast, but I may in the future. I welcome help in this area. Enjoy, Jesse V. signature.asc 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] Future Onion Addresses and Human Factors
On Aug 8, 2015, at 12:36 PM, Alec Muffett al...@fb.com wrote: 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 For the avoidance of doubt: I am not proposing use of special-case capital letters for checksums. I merely use capital letters for emphasis. — Alec Muffett Security Infrastructure Facebook Engineering London 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] Future Onion Addresses and Human Factors
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 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] First release of OnioNS for beta testing
Fantastic work. Will test it. Xinwen Fu On Aug 8, 2015, at 2:45 AM, Jesse V kernelc...@riseup.net wrote: Happy Saturday everyone, At long last, 310 commits later, I am pleased to present a release of the Onion Name System (OnioNS), a DNS for Tor hidden services. This release is a usability test; it offers reliable behind-the-scenes integration with the Tor Browser, a friendly command-line dialog for claiming domain names and subdomains, and many options for hosting and configuring a server. The system utilizes two servers: a single Quorum node which hidden services upload their claims to and another server which clients query against. I am looking for feedback as to how usable the system is and areas where it could be improved. Most of the changes going forward will be behind-the-scenes. The software is divided into three primary pieces, OnioNS-client, OnioNS-HS, and OnioNS-server. These all have OnioNS-common (a shared library) as a dependency. You can install whichever one you'd like, or all of them. This software is currently Linux-only, and Debian 7 and 8, Ubuntu 14.04 - 15.10, Mint 17 - 17.2, and Fedora 21 - 23 are supported. I provide packages for Debian 7 and a software repository for currently-supported versions of Ubuntu and Mint on 32-bit, 62-bit, and ARM systems. If possible, please use the repository. Please see the READMEs in the following repositories for more information, including installation, initialization, and configuration procedures. Manpages are also included for your convenience. https://github.com/Jesse-V/OnioNS-common https://github.com/Jesse-V/OnioNS-client https://github.com/Jesse-V/OnioNS-HS https://github.com/Jesse-V/OnioNS-server Please star the repository if it works well for you. I have claimed example.tor for my project's HS and claimed the arma.example.tor subdomain that points to Roger's site, so you can test this from the client. Please open a ticket if you find a new bug, or contact me if you don't have a Github account. A brief FAQ: Q: How does one pronounce OnioNS? A: As one would pronounce the lowercase form: onions, the plural of onion. Q: It only takes a couple of minutes to claim a domain name, isn't that too easy? A: In this release, I have set a very small difficulty level. It will certainly be harder in the future and more counter-measures are being considered. Also, since the claims are not yet saved to disk, I offer no guarantee of their long-term survival. Q: Should I use this on production hidden services? A: No, this software is not ready. This release introduces _features_, not security. Tor circuits are used on both the client and HS side, but I can't guarantee that my SOCKS use is leak-proof, for example. I'm asking for help with finding bugs that may compromise anonymity. Q: I'm running Windows/OSX/BSD/Arch/Gentoo/LFS/etc, can I test OnioNS? A: Yes, but I'm not currently supporting that environment, so you're mostly on your own. However, if you can give me compilation instructions, I may be able to. I am also looking to coordinate with anyone familiar with RPM or Windows development. Q: Is there security on your network communications? A: Client and HS communication occurs over Tor circuits, and there are some integrity checks, but simply getting everything to work is the priority here. Most of the infrastructure is set up so adding signatures and such will be easy, but that is next on the list. Once that occurs, the name server (Mirror) the client uses can be malicious with no significant impact. Q: Where can I learn more about this project? A: The normal project page, onions55e7yam27n.onion, is currently being rewritten. A simple page is in its place, so example.tor is still there. Literature on this project may be found at https://github.com/Jesse-V/OnioNS-literature. Please see the PDFs under the respective folders. Note that the distributed design will be changing to use George's commit-and-reveal scheme. Q: Are the servers reliable enough to run under Comcast? A: I have not tested them in production or otherwise under https://github.com/tylertreat/comcast, but I may in the future. I welcome help in this area. Enjoy, Jesse V. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
Hi Alec, On Sat, Aug 08, 2015 at 11:36:35AM +, Alec Muffett wrote: 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. :-) These are all good points. Not sure you are so much kicking off as joining some discussions. Maybe you will help pull several discussions into some sort of coordination. Anyway, I would say that there have been broadly two approaches to human factors and onion addresses which the above should complement well. One is to produce human meaningful names in association with onion addresses. Coincidentally Jesse has just announce to this same list a beta-test version of OnionNS that he has been working on for the Tor Summer of Privacy. See his message or https://github.com/Jesse-V/OnioNS-literature The other that I am aware of is to bind onion addresses in a human meaningful way to existing names, typically registered domain names, but could be e.g. a Facebook page rather than a domain name per se. A preliminary description of this can be found in Genuine onion: Simple, Fast, Flexible, and Cheap Website Authentication. Both paper and slides pdf can be found under http://ieee-security.org/TC/SPW2015/W2SP/ I have since that presentation been talking to Let's Encrypt folk and others about ways to expand and revise the ideas therein. Some of us have also worked on a related Tor Proposal on single onion services (aka direct onion services vs. location-hidden aka double onion services) that would be posted if I could ever find time to just add a little more to make it self-contained. We expect to have a revised and expanded version of the above paper in the not too distant future. (This week I'll be giving a course about Tor at the SAC Summer School and the Stafford Tavares Lecture at SAC in New Brunswick, but will be almost completely skipping onion services since there is basically infinite amounts of Tor things to talk about.) Picking this up again significantly in about a week and a half or thereabouts. aloha, Paul ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On Sat, Aug 08, 2015 at 11:36:35AM +, Alec Muffett wrote: 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 agdjd-recognisable-word-kjhsdhkjdshhlsdblahblah.onion I'm a fan: https://trac.torproject.org/projects/tor/ticket/15622 Though I fear my point in the ticket about the Host: header might be a good one. --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] collector problems since 2015-08-07 18:00?
Hi, I was wondering why onionoo reported empty platform strings for a growing number of relays. I wanted to confirm that by looking at collector data, but then I noticed that there is a problem with collector data itself. Files in [1] usually have a size of around 1 MB, currently they are at 1KB (basically empty). @thomas: Is that the cause for your onionoo instance issue? [1] https://collector.torproject.org/recent/relay-descriptors/server-descriptors/ signature.asc 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] Future Onion Addresses and Human Factors
Gah, I am evidently having a bad day with e-mail, so I am going to send a typo correction with this and then go do something else instead. Corrections in caps, below. — Alec Muffett Security Infrastructure Facebook Engineering London On Aug 8, 2015, at 2:14 PM, Alec Muffett al...@fb.com wrote: Please let a thousand discovery mechanisms bloom - including peer-to-peer directories and tweeted URLs. But, what they boil down to, please let *that* be human-readable, too. The more I THINK about it, the more I like: a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdxxx.onion …where the final “xxx” is a 15-bit truncated secure hash of the rest of the original raw address bitstring. That way people looking to quickly compare addresses can check the first QUINTET, and the last, and sample a few of the inner ones (“…people compare glyphs not words…” / “there’s IEVXD and there’s E0RFF, I like that one, it’s like Eeyore in Winnie-The-Pooh, and 0WLGM reminds me of Owls) and be reasonably satisfied and reasonably secure. And the XXX can be checked by the browser and tell the user that they’ve goofed-up cut/paste/typing-it-in. And then they bookmark it once it loads. 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] Future Onion Addresses and Human Factors
— Alec Muffett Security Infrastructure Facebook Engineering London On Aug 8, 2015, at 2:05 PM, Roger Dingledine a...@mit.edu wrote: https://urldefense.proofpoint.com/v1/url?u=https://trac.torproject.org/projects/tor/ticket/15622k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0Am=t0VcFezNAZohjkc7dkqY5Pak9%2BW62AHKDN8z436MZq8%3D%0As=50006f472990c7b35011656eec44171543f66f719759d7ee5fd9fdc31fc9b70d https://urldefense.proofpoint.com/v1/url?u=https://trac.torproject.org/projects/tor/ticket/15622k=ZVNjlDMF0FElm4dQtryO4A%3D%3D%0Ar=PKCvk5ihsZdnlobuFIuhTw%3D%3D%0Am=t0VcFezNAZohjkc7dkqY5Pak9%2BW62AHKDN8z436MZq8%3D%0As=50006f472990c7b35011656eec44171543f66f719759d7ee5fd9fdc31fc9b70d 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] Future Onion Addresses and Human Factors
On Aug 8, 2015, at 1:44 PM, Paul Syverson paul.syver...@nrl.navy.mil wrote: Hi Paul! I think it would be valid to propose a third direction, which is to partially give-up arguing about the importance of Zooko’s Triangle and instead make attempts to meet human beings and computers somewhere in the middle. I don’t believe that this direction should preclude development of the other two - they might indeed be complementary - but making Onion addresses accessible in the ways that an IPv4 “dotted quad” is, or that an IPv6 “::” field-pad does, cannot be a bad thing. There is, as you point out: One is to produce human meaningful names in association with onion addresses. …which is akin to the layer that DNS provides atop IP addressing; everyone with a domestic DSL router probably has “http://192.168.1.1 http://192.168.1.1/” bookmarked somewhere, which is more direct and unambiguous than the “http://router http://router/.local” that it may also masquerade as, by providing DNS bootstrap through DHCP. The other that I am aware of is to bind onion addresses in a human meaningful way to existing names, typically registered domain names, I recall the discussion we had inside Facebook, along the lines of “why don’t we register “onion.facebook.com” and issue a redirect, rather than forcing people to type this gibberish?” - an argument which was won by the observation “we are putting this out for people to have trust, and why should we make them trust DNS+redirection when we can instead give them something direct and unambiguous You’ll gather that I like “direct and unambiguous”. :-) Hence: let there be innovation. Please let a thousand discovery mechanisms bloom - including peer-to-peer directories and tweeted URLs. But, what they boil down to, please let *that* be human-readable, too. The more I like about it, the more I like: a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdxxx.onion …where the final “xxx” is a 15-bit truncated secure hash of the rest of the original raw address bitstring. That way people looking to quickly compare addresses can check the first octet, and the last, and sample a few of the inner ones (“…people compare glyphs not words…” / “there’s IEVXD and there’s E0RFF, I like that one, it’s like Eeyore in Winnie-The-Pooh, and 0WLGM reminds me of Owls) and be reasonably satisfied and reasonably secure. And the XXX can be checked by the browser and tell the user that they’ve goofed-up cut/paste/typing-it-in. And then they bookmark it once it loads. - alec — Alec Muffett Security Infrastructure Facebook Engineering London 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] collector problems since 2015-08-07 18:00?
In the event of collector missing data, there are (at least) two backup instances. One is at bwauth.ritter.vg - no website, just files. Does that have the same issue? -tom ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On 08 Aug (11:36:35), Alec Muffett wrote: Hi All, Having Beer with Donncha, Yan and others in Berlin a few days ago, discussion moved to Onion-Address Human Factors. Beers, very nice! :) [snip] 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 That I like quite a bit! Right now, with the 16 char address, I doubt very much that people actually type them in the browser, I bet it's still and will continue to be Copy-Paste. As for the verification part that is making sure you have the right .onion, I'm pretty sure this is just ignore by most users and that it is actually worst with vanity address because as long as I see facebook in there, that's good enough. Ok, you guys have a pretty epic one that is quite noticeable but let's take Wikileaks upload page for instance wlupld3ptjvsgwqw.onion, only seeing wlup is MOST probably way enough for most of the users and 12 characters are then ignored. (Altough, most users probably rely on the CA-mafia to get their .onion in a trusted ways so anycase the verification of .onion situation is pretty bad. ;) With banks of char, it makes it much more easier for someone to remember one of them and verify that at least the one I remember is there. It's not perfect but it's a damn good start imo. I remember reading a while back a study about research done at Bell Labs when they were trying to come up with a standard length for the phone numbers in North America (now 7 digits + 3 area code). One of the reasons in the end was the human brain capability of quickly, and for a reasonable amount of time, remembering = 7 digits. So, this approach takes advantage of that human brain quirk and we should definitely use it to improve onion address verification by users. With 52 characters, there could be 7 blocks of 7 chars (49) and a last block of 3 chars + the 4 unused bits (see below for those). If you remember at least one of those blocks somewhere in the string, I say amazing improvement! (I would NOT go with different length though, I bet *everyone* will end up remember the smallest one so have them at least all the same length or some of them bigger.) 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 See section 1.2 of proposal 224 (NOT 244 ;), there are 4 unused bits when using base32 encoding. I remember we had a discussion about those at the HS meeting [1], ideas where the length, very small checksum (a la credit card), or human readable word. So definitely, this needs to be clarified in the proposal. 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. :-) Totally and if by some email magic we reach a concensus, this should be added to the prop#224 before we do implement it. (Or even it's own proposal if too big.) Cheers! David [1] https://blog.torproject.org/blog/hidden-service-hackfest-arlington-accords - alec — Alec Muffett Security Infrastructure Facebook Engineering London ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] collector problems since 2015-08-07 18:00?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 In the event of collector missing data, there are (at least) two backup instances. One is at bwauth.ritter.vg - no website, just files. Does that have the same issue? https://bwauth.ritter.vg/rsync/relay-descriptors/server-descriptors-cat/ looks fine. -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJVxg8pAAoJEFv7XvVCELh0ccUP/2VPE/P96qP7ujbNcoM8/bYJ /b8G5NpKQggpMsAjXVUq9P2M4rYhYkzLn3wvyn8paXBkX/HX5d3574lsFQ7W/C0x 9V8IVc+uqqP3EeVIOg5kPrHblG+UuQ8ldYwwDKmY/RgrD5772m3LAa9WY/hrpfiC FQavIUWeIn1UPyKtCpfBWDwbzQ0zT/BC4Ak74AGJA6GN9q9NXQFbtcQtoBTXdaGc RPmzas4meEkGez7tj418Ku8UFxckPAA7yWCmzzwSPckfCzv54IxXso4tKVUEZxi+ lvjEJ0WVbKsPp0eO3ljKnieRgeB3zHRqRQZShesY5c5l6alZCcow4K9V9CeHsivn LaeoN1H/vXKCL8WROEK1hSEv8YbE3uOZ2u+G6O8tBPr8uSQpecLQFO/74dj32gD5 d727W9M8hKcguRaUg2QzxNe7cdy2dfWIlxKGomlEr7GK4FYJljMGxnaOe4vHoCxR ZMZgiSbnaGVAmlPBfVoOAMvemN5+YXUgWPbucFp0b7bjGlk1aVO1/PoU3OwdGw9h go+7OqFuYJvwu+KrhaPkM/DBceX9IbNpw44D9ox0cB/D+UddJXVknzxXuPw5TwZ1 U9ilD/SYD1QY2EgRz0LVL2qnwZzPUDffz0ZgLFzRRK1EVjrrCiDa1uItY2x3EA52 YqLmUMVFQhQ3VbjOnQfW =NQM+ -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] collector problems since 2015-08-07 18:00?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 08/08/15 16:16, nusenu wrote: In the event of collector missing data, there are (at least) two backup instances. One is at bwauth.ritter.vg - no website, just files. Does that have the same issue? https://bwauth.ritter.vg/rsync/relay-descriptors/server-descriptors-cat/ looks fine. Oh, crap. That's my fault. I deployed a CollecTor patch yesterday that's acting up. I know what the problem is, I now need to fix it and clean up the mess. Ewww. Here's the (still broken) patch, if you care: https://gitweb.torproject.org/karsten/metrics-db.git/commit/?h=no-catid=2b2e2d7721e2300a4d89ebfa78c326138a02a0f7 (If you really care, the problem is that I forgot to update the boolean[] arrays.) Good catch, Nusenu! All the best, Karsten -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVxhveAAoJEJD5dJfVqbCr/EEIAMk26nuMJmjwtLbedWA9ib37 DQmGUCyRkEj7d9ZsdYmNLVkKkaupP4bYzD2wdfEWcsLPXTvcYZrDakw2ALoIbAIK M6cMYqPV+z9U1j9Tk2sUrKhiziJ5O/TDWNaT5zKk9d9e+ese3PCqf6TCSEBKb2UK nPiaz5bxxWEBiCMPC6Rq9qh4Zu511i3TSnxPAu/dW9S/Q/AfeoYSj4uTHJHbYsF+ HiuU96Sirl+8i1z6tJ9FU8m9trb2xyCD3u6/Ry+lu2n3FepcgEQpHhVTXG4TCiMU 8y5eJV4cgdTyuKVZWhJ7r4Al0BhjtTVHZ/VIeXsq/10fzKG5QHnjU9Y8VfuHWCU= =PltI -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Invitation to participate in a survey about Tor's future
Hello people of tor-dev, You may have heard that I'm working with the Tor Project to help it develop a strategic plan [1]. To kick off, we're running a survey asking Tor-related people their opinions about Tor and its future. I'd like to invite you to participate: https://www.surveymonkey.com/r/tor_core The survey's pretty short and should take about 15 minutes to fill out. If you have time to do it within the next few days, that would be great. We'd really appreciate your input :) If you've got questions, there's an FAQ here (or you can just ask me here on this list). https://trac.torproject.org/projects/tor/wiki/org/Strategy/SurveyFAQ Thanks, Sue [1] http://suegardner.org/2015/05/20/why-im-working-with-tor-and-first-look/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
Hi, Right now, .onion URLs are not human readable. Neither are they easy for humans to recognise OR recall. The way information is presented to humans can greatly influence how we recognise, recall it and process it. The ideal situation is for the user to recognise a piece of information. It takes less cognitive processing to do this. This is not possible here as they are required to type the URL into the browser. In this case the user will be required to recall the address, as someone reads it out to them, or they read it off a device screen. Recall is more difficult for humans to carry out. Alec’s idea below is essentially the “chunking” of .onion addresses. It is an often used technique when it comes to many human-computer interactions that require humans to process information. Research shows that humans’ short-term memory” has different characteristics to our “long-term memory. [1, 2] This short term memory (also called working memory) provides temporary storage of information and has a limit (often compared with a channel's capacity). This working memory capacity can be increased by information chunking - the information is recoded into many chunks which contain a number of bits per chunk. Bit in this context means an item of information. In our context it would be equivalent to a letter or number in the URL. As stated in Millers paper below the so-called 'magic number’ is seven +/-2 bits, per chunk. While the definition of a chunk is not strict, in terms of .onion addresses, this could be achieved through experimentation and drawing on already published research. (Haven’t found any yet, but thats not to say it isn’t out there). The lower end of Millers chunk size, 5, would be a good place to start. The human is able to see patterns, categories, groupings and use this to increase her/his working memory temporarily. As someone mentioned already this aids humans in recalling telephone numbers, 08057-282-9320, instead of 080572829320. In this case I have chunked this number to take into account the chunk 08057 because for me it is a manageable sized chunk and the pattern “282” in the middle. Chunking may also assist the user in recognising they have transferred the information correctly. It would be interesting to observe in a usability test, how a user would transfer a .onion address from say, a chat session to their browser. If the address was chunked it could be expected it would assist them in seeing the difference between: a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sd5sp.onion the real URL and shdue-duqld-7p3i5-ievxd-m6oeu-27388-g607q-e0rff-dw9jm-ntwkd-srfcg.onion a malicious URL. It would be wonderful to see some user research into this. In terms of UI, could the Tor Browser warn the user “This looks similar to, but not the exact same as, a URL you have stored. Do you really want to follow the link?”? There is however, a balance to be struck with using information chunking. A users' working memory can be overloaded with presenting them with too much information. This may be an issue here as the proposed .onion address is 52 letters? The ideal situation would be for the information to eventually transfer from the users working memory to their long-term memory so they can type the address every time they want to - the address would be memorised. I would suspect this will not be achievable in most instances, as the process of “storing” information to their long term memory requires repeated exposure to the information - I would not expect the user to willingly type a 23 word long URL (256 bits, 11 bits in a word?) into their browser repeatedly. This could easily be overcome by the user bookmarking the URL in the Tor browser for future use, once it has been entered correctly. This would be an improvement over the current situation. The second topic would be to work out what character would be best used to visually represent that chunking. For telephone numbers this can be a space, hyphen, period, forward-slash. It would be best to find out from users (or previous research) what would help here. Again, experimentation could point to characters that would help here. Please consider carrying out some research into this. The above will improve the situation, but we would still be requiring the user to recall multiple random strings of characters (even with a checksum). While I don’t know about the possibility of this from a technical point of view, an improvement on this (from the point of view of the usability of .onion addresses) *may* be to produce pronounceable word .onion addresses. [3, 4] So instead of: a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdt5sp.onion it would be: correct-battery-horse-staple-chair-banana-table-river-pizza.onion or using an already established dictionary: fat-gin-keg-log-oak-pit-pup-darn-fury-knee-mark-year-wand-tram-it.onion If the goal is to improve the
Re: [tor-dev] Future Onion Addresses and Human Factors
On Sat, Aug 8, 2015 at 7:36 AM, Alec Muffett al...@fb.com wrote: 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, a1uik-0w1gm-fq3i5-ievxd-m9ceu-27e88-g6o7p-e0rff-dw9jm-ntwkd-sdXXX.onion Checksums need to detect more bits than the 0-n number of expected errors. At the apparent 56^(26+10) ~=2^205 above, there may also be no need to give typo feedback if the error rate is unlikely to result in some other valid address. And just where exactly and in what protocols and apps are going to build in that feedback popup... browsers? ssh? MUA? ping? skype? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Future Onion Addresses and Human Factors
On Sat, Aug 08, 2015 at 11:36:35AM +, Alec Muffett wrote: 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 We could make the .onion URL human recognizable, but not actually human typeable. I like key poems : https://moderncrypto.org/mail-archive/messaging/2014/000125.html In fact, there is no need to conceptualize this as a URL except for convenience. We could provide a .onion key poem library so that TBB, etc. can display them when you mouse over the URL bar. 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. There are a couple choices for mappings for the non-essential characters in base 32 encodings. I believe the usual one was designed to make spelling fuck impossible or some stupidity like that. I think the one GNUNet uses was selected to provide as much flexibility as possible. It's no worse for type-o squating if u and v map to the same value and a few similar things. 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 Yes, checksums help enormously. Interestingly, there are situations where you're entering a password, but the machine should add a checksum while remaining human readable. In those situations, there is a clever suggestion by Christian Grothoff that an algorithm tweak the human readable passphrase until some hash is zero. Pond's PANDA key exchange is an example of when one should do this, although Pond does not. I doubt that's relevant for .onion URL itself, but maybe worth considering for vanity key poems or something. On Sat, 2015-08-08 at 09:05 -0400, Roger Dingledine wrote: I'm a fan: https://trac.torproject.org/projects/tor/ticket/15622 Though I fear my point in the ticket about the Host: header might be a good one. A priori, pet names sounds vaguely like the GNU Name System (GNS), meaning short names consistent for the user, but not globaly unique. In GNS, there is a .short.gnu domain so that after you visit facebook's blah.zkey then facebook.short.gnu becomes a meaningful domain. I'd worry however that, if your anti-facebook friend jake sets his preferred short name to facebook, and you visit his zone fist, then he gets facebook.short.gnu on your machine. TOFU world problems. ;) On Sat, 2015-08-08 at 08:44 -0400, Paul Syverson wrote: One is to produce human meaningful names in association with onion addresses. Coincidentally Jesse has just announce to this same list a beta-test version of OnionNS that he has been working on for the Tor Summer of Privacy. See his message or https://github.com/Jesse-V/OnioNS-literature OnioNS has a relatively weak adversary model, like Namecoin, right? It's certainly plausible that's good enough for most users, including all financial users, but maybe not everyone. There are several approaches to improving upon that adversary model : - Pinning in the Name System - If a name X ever points to a hidden service key, then X cannot be registered to point to a different hidden service key for 5 years. Alternatively, if our name system involves another private key, then X cannot be registered under another private key for 5 years. - Pinning/TOFU in the browser - If my browser ever visits X then it locks either the .onion key and/or the TLS key permanently. Alternatively pin both but one at a time to change. Sounds bad for Tails, etc. though. - Awareness - Just yell and scream about how OnioNS, Namecoin, etc. are nowhere near as secure as a .onion address. And especially tell anyone doing journalism, activist, etc. to use full .onion addresses. - Key Poems maybe? Jeff signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Invitation to participate in a survey about Tor's future
Hi Sue, On 9 Aug 2015, at 04:34 , Sue Gardner susanpgard...@gmail.com wrote: Hello people of tor-dev, You may have heard that I'm working with the Tor Project to help it develop a strategic plan [1]. To kick off, we're running a survey asking Tor-related people their opinions about Tor and its future. I'd like to invite you to participate: https://www.surveymonkey.com/r/tor_core SurveyMonkey doesn't work at the highest Tor Browser security level, because it requires JavaScript. If you've got questions, there's an FAQ here (or you can just ask me here on this list). https://trac.torproject.org/projects/tor/wiki/org/Strategy/SurveyFAQ And I believe that's covered by this FAQ: What if someone doesn't want to use SurveyMonkey? Anybody who doesn't want to use SurveyMonkey can email Sue their responses and she will include them in the aggregated results. Sue's email address is susanpgardner(at)gmail.com, and her public key is here https://keybase.io/spg/ Regards Tim (teor) Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC 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] Future Onion Addresses and Human Factors
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/08/2015 11:39 PM, Jeff Burdges wrote: On Sat, 2015-08-08 at 08:44 -0400, Paul Syverson wrote: One is to produce human meaningful names in association with onion addresses. Coincidentally Jesse has just announce to this same list a beta-test version of OnionNS that he has been working on for the Tor Summer of Privacy. See his message or https://github.com/Jesse-V/OnioNS-literature OnioNS has a relatively weak adversary model, like Namecoin, right? It's certainly plausible that's good enough for most users, including all financial users, but maybe not everyone. There are several approaches to improving upon that adversary model : - Pinning in the Name System - If a name X ever points to a hidden service key, then X cannot be registered to point to a different hidden service key for 5 years. Alternatively, if our name system involves another private key, then X cannot be registered under another private key for 5 years. - Pinning/TOFU in the browser - If my browser ever visits X then it locks either the .onion key and/or the TLS key permanently. Alternatively pin both but one at a time to change. Sounds bad for Tails, etc. though. - Awareness - Just yell and scream about how OnioNS, Namecoin, etc. are nowhere near as secure as a .onion address. And especially tell anyone doing journalism, activist, etc. to use full .onion addresses. I'm not 100% sure what you mean by saying that OnioNS's and Namecoin's adversary models are comparable. To my knowledge, they're quite different in the respect that OnioNS relies on a quorum of directory authorities, while Namecoin relies on a quorum of mining hashpower. Which is better probably depends on your threat model. I did a rough calculation about a year ago of how much it would cost to buy ASIC miners that could 51%-attack Namecoin, and it came out to just under a billion USD. Of course, a real-world attacker would (in my estimate) probably be more likely to try to compromise existing miners (via either technical attacks, extortion/blackmail/bribery, or legal pressure). Note that right now -- though hopefully not in the future - -- this kind of attack is easier than it should be because a majority of Bitcoin hashpower (and with it Namecoin) is located in China. I'm not sure about OnioNS's design, but in Namecoin's design, a 51% attack is easily detectable (you'll see blocks getting orphaned in a way that makes a targeted name not get renewed even though the renewal transaction is clearly visible and being relayed). It's also easily detectable specifically which names were targeted by the attack. Regarding pinning, there are also some half-formed proposals related to that for Namecoin, which would make a 51% attack ineffective at stealing a name (it would instead simply be a DoS attack on that name, which would cost continued hashpower to sustain). Personally I'd love to see these proposals implemented, although getting the appropriate level of review to make sure everything works as we intend takes some time. (This would be a hardfork to the consensus rules, so it takes a lot of carefulness.) In any event, security only matters if the end users can effectively use it. An end user will be much more likely to notice when a Namecoin or OnioNS name changes, compared to when a .onion name changes. So this isn't really a clear win for .onion -- it's a tradeoff, and which is more secure depends on which end users we're talking about, and what threat model we're dealing with. There are probably a significant number of cases where Namecoin (or OnioNS, or something similar to either) would defend against attacks that .onion wouldn't. (The inverse is, of course, also probably the case.) Cheers, - -Jeremy Rand -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVxtuSAAoJEAHN/EbZ1y06SVoQAMaa03n2/onHeqtwMzfSRwEO IzrsyrxLCxJhPCAGH4gvuGkU/rqNJRT4BhwwTCvtgoEnYNWe0dxoc29bNM76KR0f Ksq5//kgm73sDyyeRw4jxP3SpMzucc1BoyTBEeJdYuL8hdBwBwkOrd32C+ee/7vu /OUzisy68apzQFHZDlXY5HS6rp+vdOj1uKUglhDM9nSx73kSdOnpvuxZm9PfYdaR OXBmZ9Lhk8hAYKhoxdTI+I5I8KNiCZV/uWkDSfDs+RUuL2dAvdEcP3uq5lQoIGyO tOgBqBSpBAk39ihA7YplmhL3YSJcQ4yfo4rY68PDby+sGI/quZ5YGJjOEyKW0TF2 uObuDQz+1ajD/WPiaQ9I6xo2jJE2vQkMrqfCe83YsR8oOmpN3f+YWm/fgs/EoDul tG50rwr76egQL+EphJFYvH35YKAwoXNowDlTpGMMCanRC0pOoQAdpmyPvJv38E56 mZSC42oeFgV/vjnSEtKBtnthfg6GHap87XHp+nX//Ry5v+fxo9t94QyGUrAxQtLQ 0MJ4athw3QTi8QJYa6y1DktbIze5dStqteBKK+W7EvrXxNS0eJYL9vJvKPEyu75x dqhzFZTsFjinv9Dgn/YG665WlvVpDkc36wn/Cj6yXP1kT2Prpo+ekmdLFxJUiQ9l zYtb7Vw4vTw0KOzsrH8E =UgpZ -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
