Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
On Wed, 2016-09-28 at 19:45 -0400, Jesse V wrote: > I am curious, what is your issue with the subdomains? Are you > referring to enumerating all subdomains, or simply being able > to confirm that a particular subdomain exists? Yes, confirmation of subdomans can become a problem in some contexts where GNS gets discussed as a possible solution. If I know that blabla.onion exists as a website, then it's good that I can learn that www.blabla.onion exists as a website. If otoh I know that blabla.zkey is a GNS record representing a Bob's contact list, then it's bad that I can learn that alice.blabla.zkey exists. Jeff p.s. In my message, I suggested roughly : Let P = p G be a elliptic curve point so that P.onion is a hidden service with abbreviated URL x. If y is a domain name element string, then y.P.onion and y.x point to Q.onion where Q = H(s,P) * P for some hash function H mapping into the scalars. And q = H(s,P) p is the private key for that HS record. Now this Q.onion HS record could simply forward users to another HS record with a private key not controlled by p. This means the owner of x & p can make the HSDirs forward requests in a verifiable way. The downside is more HS records. This could help create a diversity of naming solutions whose TLDs (x above) are controlled by different authorities. It's not helpful if you want x to be controlled in some distributed way though. In fact, I suppose most Tor name service proposals would be distributed, giving my idea only very limited usefulness. 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] prop224: Ditching key blinding for shorter onion addresses
On 09/27/2016 11:15 AM, Jeff Burdges wrote: > There were a couple reasons I stopped the work on integrating > GNS with Tor, which Christian asked me to do : First, I did not like > that users could confirm that a particular subdomain exists if they know > the base domain's public key. Second, I disliked the absence of the > collaborative random number generator protections you guys added to Tor. I am curious, what is your issue with the subdomains? Are you referring to enumerating all subdomains, or simply being able to confirm that a particular subdomain exists? If I know that google.com exists and I am looking for Google Maps, it seems reasonable that I might try to look up maps.google.com. I wasn't able to find a practical solution against enumeration for OnioNS, but I am curious what your exact concerns are here. -- Jesse 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] prop224: Ditching key blinding for shorter onion addresses
I'll add a note on GNS to your wiki George, but.. On Sat, 2016-08-20 at 16:48 +0300, George Kadianakis wrote: > We really need to start serious work in this area ASAP! Maybe let's > start by > making a wiki page that lists the various potential solutions (GNS, > Namecoin, > Blockstack, OnioNS, etc.)? There were a couple reasons I stopped the work on integrating GNS with Tor, which Christian asked me to do : First, I did not like that users could confirm that a particular subdomain exists if they know the base domain's public key. Second, I disliked the absence of the collaborative random number generator protections you guys added to Tor. Now my first concern is not an issue in the context of a "name system" for servers, well it's clearly desirable there. It's just not desirable if you start talking about using the name system for more social applications, which people do for GNS. Also, my second concern is not an issue if you envision the system being backed only by Tor HS record, not GNS records. In that scenario, the cost you pay is (1) you need a forwarding record for Tor HSs, and (2) sites with subdomains need to continually reupload those them as the collaborative random number changes. This does not give you global names obviously, but it does give you GNS style non-global names in the threat model desired by the 224 or whatever. In effect, you'd use the existing HSDirs for non-global name links, instead of some new PIR scheme like U+039B and others proposed. Now non-global names are not necessarily useful unless people can socially construct naming hierarchies around them, but that's doable. And they can refer to each other. etc. Anyways, I think adding forwarding records and the signing key derivation trick from GNS to Tor might give the Tor project a way to let different naming schemes develop organically. And not be overly responsible for issues arising from Zooko's triangle. tl;dr I'm not saying GNS itself is the way to go, but GNS's subdomoman crypto trick along with Tor's existing HSDir structure might improve things. 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] prop224: Ditching key blinding for shorter onion addresses
Jeremy Rand writes: > [ text/plain ] > George Kadianakis: >> Lunar writes: >> >>> [ text/plain ] >>> George Kadianakis: this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal. >>> >>> Taking a step back here, I believe the size of the address to be a >>> really minor usability problem. IPv6 adressses are 128 bits long, and >>> plenty of people in this world now access content via IPv6. It's not a >>> usability problem because they use a naming—as opposed to >>> addressing—scheme to learn about the appropriate IPv6 address. >>> >> >> That's true. Naming systems are indeed the way to go wrt UX. The future sucks >> if our users are supposed to use 24 (or 56) random characters as addresses. >> >> That said, the current IPv6 naming scheme (DNS) is far from perfect as >> well. Tor would never use it (or any other system with similar threat model). >> >> Furthermore, all the _secure naming systems_ that have been suggested have >> their own tradeoffs. They are either centralized, or they use blockchains, or >> they require money, or they require a whole network/community to exist, or >> they >> have annoying name-squatting issues, or they require a non-anonymous >> registration, or they save HS history on disk, or their protocol is three >> times >> more complicated than Tor itself, or ... >> >> So it's not like we have the perfect solution on the naming scheme right now. >> We likely need plenty of trial experimentation before we decide on one (or >> multiple) naming cheme becoming the official. >> >> We really need to start serious work in this area ASAP! Maybe let's start by >> making a wiki page that lists the various potential solutions (GNS, Namecoin, >> Blockstack, OnioNS, etc.)? > > I'd be happy to provide feedback on the Namecoin section of such a wiki > page. > Hello people interested in this topic, I made a wiki page for Naming Systems here: https://trac.torproject.org/projects/tor/wiki/doc/OnionServiceNamingSystems Feel free to start adding information and links and make it look nicer. Let's try to build a good knowledge base that will help us take informed decisions. Please try to maintain some sort of consistent structure through the document. (In the unlikely case where the doc gets out of hand, I will try to find some time to curate it.) Thanks! :) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
George Kadianakis: > Lunar writes: > >> [ text/plain ] >> George Kadianakis: >>> this is an experimental mail meant to address legitimate usability concerns >>> with the size of onion addresses after proposal 224 gets implemented. It's >>> meant for discussion and it's far from a full blown proposal. >> >> Taking a step back here, I believe the size of the address to be a >> really minor usability problem. IPv6 adressses are 128 bits long, and >> plenty of people in this world now access content via IPv6. It's not a >> usability problem because they use a naming—as opposed to >> addressing—scheme to learn about the appropriate IPv6 address. >> > > That's true. Naming systems are indeed the way to go wrt UX. The future sucks > if our users are supposed to use 24 (or 56) random characters as addresses. > > That said, the current IPv6 naming scheme (DNS) is far from perfect as > well. Tor would never use it (or any other system with similar threat model). > > Furthermore, all the _secure naming systems_ that have been suggested have > their own tradeoffs. They are either centralized, or they use blockchains, or > they require money, or they require a whole network/community to exist, or > they > have annoying name-squatting issues, or they require a non-anonymous > registration, or they save HS history on disk, or their protocol is three > times > more complicated than Tor itself, or ... > > So it's not like we have the perfect solution on the naming scheme right now. > We likely need plenty of trial experimentation before we decide on one (or > multiple) naming cheme becoming the official. > > We really need to start serious work in this area ASAP! Maybe let's start by > making a wiki page that lists the various potential solutions (GNS, Namecoin, > Blockstack, OnioNS, etc.)? I'd be happy to provide feedback on the Namecoin section of such a wiki page. Cheers, -Jeremy Rand 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] prop224: Ditching key blinding for shorter onion addresses
Hi! George Kadianakis a écrit : > Lunar writes: > >> [ text/plain ] >> George Kadianakis: >>> this is an experimental mail meant to address legitimate usability concerns >>> with the size of onion addresses after proposal 224 gets implemented. It's >>> meant for discussion and it's far from a full blown proposal. >> >> Taking a step back here, I believe the size of the address to be a >> really minor usability problem. IPv6 adressses are 128 bits long, and >> plenty of people in this world now access content via IPv6. It's not a >> usability problem because they use a naming—as opposed to >> addressing—scheme to learn about the appropriate IPv6 address. >> > > That's true. Naming systems are indeed the way to go wrt UX. The future sucks > if our users are supposed to use 24 (or 56) random characters as addresses. > > That said, the current IPv6 naming scheme (DNS) is far from perfect as > well. Tor would never use it (or any other system with similar threat model). > > Furthermore, all the _secure naming systems_ that have been suggested have > their own tradeoffs. They are either centralized, or they use blockchains, or > they require money, or they require a whole network/community to exist, or > they > have annoying name-squatting issues, or they require a non-anonymous > registration, or they save HS history on disk, or their protocol is three > times > more complicated than Tor itself, or ... After some discussions, I started to write the specifications of a naming service. It is based on Reed-Solomon[0] - shards are distributed over multiple nodes (which are HS to) and then signed. Thus, there is no node which has the complete registrations information. To recover the entire list of HS, multiple nodes have to be compromised or brute forced. Shards are replicated which helps to prevent a DoS. Furthermore, registrations are anonymous and volatile - the HS registers itself, a registration has to be refreshed every hour or every day (the refresh period has to be well studied in order to have a reasonable traffic). Volatility allows to keep mapping tables in RAM. Regarding the trade-offs listed above, the only one I cannot handle is the name squatting. Regarding the others, the protocol will be simple (based on Tor communication) and few nodes are required to start the service. > > So it's not like we have the perfect solution on the naming scheme right now. > We likely need plenty of trial experimentation before we decide on one (or > multiple) naming cheme becoming the official. > > We really need to start serious work in this area ASAP! Maybe let's start by > making a wiki page that lists the various potential solutions (GNS, Namecoin, > Blockstack, OnioNS, etc.)? I would be happy to take part of a working group which tackles this topic. Regarding encoding, we can even use base64, base91, etc. I wrote a stupid HS pet name generator[1] which encodes the onion address with a dictionary of real words. It generates a set of 16 words for next gen HS. > >> While I do think we should think of nicer representation for the new >> addresses than base32, and we should adress that, working on a naming >> system sounds like an easier way out to improve onion services >> usability than asking people to remember random addresses (be them 16 or >> 52 characters-long). >> > > Agreed that base32 is not very good as far as encoding goes. > > Regardless of the naming system that we need to deploy, we should also > acknowledge that we need a good address encoding scheme anyway, as not all > HSes > will use the naming system. This is also the case with IP addresses: many > people mess with IP addresses everyday (for config files, etc.) > > I recently read this paper from USENIX which is a UX study on fingerprint > encodings: > > https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/dechand > We might be able to learn somethign from it. For example, they found out that > alphanumeric encodings (like base32) make for the worst experience when > compared to other encodings (pure numeric, unrelated words, sentences, etc.). > > Finally, if we acknowledge that at least some people will have to mess with > the > raw addresses themselves, another benefit of the addresses being small is that > they are easier to verify by hand (verifying a 24 characters fingerprint, is > easier than verifying a 54 characters fingerprint). > > >> (I now plenty of people who type “riseup” in the Google search bar of >> their browser to access their mailbox… They don't even want to/can't remember >> an URL. Hardly a chance they will remember an onion address, whatever >> its size.) >> > > Indeed. We need a good naming scheme if we ever hope for onion services to > become widespread. > >> Maybe it would be worthwhile to ask the UX team for input on the topic? >> > > I think that would be a good idea indeed. > Cheers! [0] https://en.wikipedia.org/wiki/Reed%E2%80%93Solomon_error_correct
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
Lunar writes: > [ text/plain ] > George Kadianakis: >> this is an experimental mail meant to address legitimate usability concerns >> with the size of onion addresses after proposal 224 gets implemented. It's >> meant for discussion and it's far from a full blown proposal. > > Taking a step back here, I believe the size of the address to be a > really minor usability problem. IPv6 adressses are 128 bits long, and > plenty of people in this world now access content via IPv6. It's not a > usability problem because they use a naming—as opposed to > addressing—scheme to learn about the appropriate IPv6 address. > That's true. Naming systems are indeed the way to go wrt UX. The future sucks if our users are supposed to use 24 (or 56) random characters as addresses. That said, the current IPv6 naming scheme (DNS) is far from perfect as well. Tor would never use it (or any other system with similar threat model). Furthermore, all the _secure naming systems_ that have been suggested have their own tradeoffs. They are either centralized, or they use blockchains, or they require money, or they require a whole network/community to exist, or they have annoying name-squatting issues, or they require a non-anonymous registration, or they save HS history on disk, or their protocol is three times more complicated than Tor itself, or ... So it's not like we have the perfect solution on the naming scheme right now. We likely need plenty of trial experimentation before we decide on one (or multiple) naming cheme becoming the official. We really need to start serious work in this area ASAP! Maybe let's start by making a wiki page that lists the various potential solutions (GNS, Namecoin, Blockstack, OnioNS, etc.)? > While I do think we should think of nicer representation for the new > addresses than base32, and we should adress that, working on a naming > system sounds like an easier way out to improve onion services > usability than asking people to remember random addresses (be them 16 or > 52 characters-long). > Agreed that base32 is not very good as far as encoding goes. Regardless of the naming system that we need to deploy, we should also acknowledge that we need a good address encoding scheme anyway, as not all HSes will use the naming system. This is also the case with IP addresses: many people mess with IP addresses everyday (for config files, etc.) I recently read this paper from USENIX which is a UX study on fingerprint encodings: https://www.usenix.org/conference/usenixsecurity16/technical-sessions/presentation/dechand We might be able to learn somethign from it. For example, they found out that alphanumeric encodings (like base32) make for the worst experience when compared to other encodings (pure numeric, unrelated words, sentences, etc.). Finally, if we acknowledge that at least some people will have to mess with the raw addresses themselves, another benefit of the addresses being small is that they are easier to verify by hand (verifying a 24 characters fingerprint, is easier than verifying a 54 characters fingerprint). > (I now plenty of people who type “riseup” in the Google search bar of > their browser to access their mailbox… They don't even want to/can't remember > an URL. Hardly a chance they will remember an onion address, whatever > its size.) > Indeed. We need a good naming scheme if we ever hope for onion services to become widespread. > Maybe it would be worthwhile to ask the UX team for input on the topic? > I think that would be a good idea indeed. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
In order to have an effective system of blinded identities, you need to have an out of band channel to transmit 128-256 bits from the server to the client. This is essential for blinding the in-band adversary to the long term shared identity between the client and server. A naming system will move that blinding data back into the in-band channel. There needs to be better tools for working with 128-256 bits of data. We have bookmarks, QR codes, and word lists etc but there is tons of room for improvement. It seems impossible to strongly blind an in band adversary while moving fewer bits through the address channel. On Sun, Jul 31, 2016 at 8:03 AM Razvan Dragomirescu < razvan.dragomire...@veri.fi> wrote: > I agree with this, I don't really see the point of making .onion names > easy to remember. If it's a service you access often, you can bookmark it > or alias it locally to something like "myserver.onion" (maybe we should > make it easier for users to do just that - an alias file for .onion > lookups, allowing them to register myserver.onion and point it to > asdlataoireaoiasdasd.onion or whatever). > > If it's a link on a Wiki or in a search engine, you just click on it, you > don't care what the name is. The only time you'd have to remember an actual > .onion address is if you heard it on the radio or saw a banner on the side > of the street while driving and had to memorize it in a few seconds. Or > maybe if you have to read the address _over the phone_ to a friend (as > opposed to mailing him the link). > > What is the exact use case of this? I'm not saying it's useless, I just > don't see the point, maybe I'm missing something. > > Razvan > > -- > Razvan Dragomirescu > Chief Technology Officer > Cayenne Graphics SRL > > On Sat, Jul 30, 2016 at 9:44 PM, Lunar wrote: > >> George Kadianakis: >> > this is an experimental mail meant to address legitimate usability >> concerns >> > with the size of onion addresses after proposal 224 gets implemented. >> It's >> > meant for discussion and it's far from a full blown proposal. >> >> Taking a step back here, I believe the size of the address to be a >> really minor usability problem. IPv6 adressses are 128 bits long, and >> plenty of people in this world now access content via IPv6. It's not a >> usability problem because they use a naming—as opposed to >> addressing—scheme to learn about the appropriate IPv6 address. >> >> While I do think we should think of nicer representation for the new >> addresses than base32, and we should adress that, working on a naming >> system sounds like an easier way out to improve onion services >> usability than asking people to remember random addresses (be them 16 or >> 52 characters-long). >> >> (I now plenty of people who type “riseup” in the Google search bar of >> their browser to access their mailbox… They don't even want to/can't >> remember >> an URL. Hardly a chance they will remember an onion address, whatever >> its size.) >> >> Maybe it would be worthwhile to ask the UX team for input on the topic? >> >> -- >> Lunar >> >> ___ >> 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 > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
I agree with this, I don't really see the point of making .onion names easy to remember. If it's a service you access often, you can bookmark it or alias it locally to something like "myserver.onion" (maybe we should make it easier for users to do just that - an alias file for .onion lookups, allowing them to register myserver.onion and point it to asdlataoireaoiasdasd.onion or whatever). If it's a link on a Wiki or in a search engine, you just click on it, you don't care what the name is. The only time you'd have to remember an actual .onion address is if you heard it on the radio or saw a banner on the side of the street while driving and had to memorize it in a few seconds. Or maybe if you have to read the address _over the phone_ to a friend (as opposed to mailing him the link). What is the exact use case of this? I'm not saying it's useless, I just don't see the point, maybe I'm missing something. Razvan -- Razvan Dragomirescu Chief Technology Officer Cayenne Graphics SRL On Sat, Jul 30, 2016 at 9:44 PM, Lunar wrote: > George Kadianakis: > > this is an experimental mail meant to address legitimate usability > concerns > > with the size of onion addresses after proposal 224 gets implemented. > It's > > meant for discussion and it's far from a full blown proposal. > > Taking a step back here, I believe the size of the address to be a > really minor usability problem. IPv6 adressses are 128 bits long, and > plenty of people in this world now access content via IPv6. It's not a > usability problem because they use a naming—as opposed to > addressing—scheme to learn about the appropriate IPv6 address. > > While I do think we should think of nicer representation for the new > addresses than base32, and we should adress that, working on a naming > system sounds like an easier way out to improve onion services > usability than asking people to remember random addresses (be them 16 or > 52 characters-long). > > (I now plenty of people who type “riseup” in the Google search bar of > their browser to access their mailbox… They don't even want to/can't > remember > an URL. Hardly a chance they will remember an onion address, whatever > its size.) > > Maybe it would be worthwhile to ask the UX team for input on the topic? > > -- > Lunar > > ___ > 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] prop224: Ditching key blinding for shorter onion addresses
Hi, Lunar: the size of the address Size *does* matter XD 128 bits long Oh my. IPv6. It's not a usability problem because .. .. no one outside of computer networking knows what it is, or that it exists (: a naming system [vs] random[ness] [regarding] the size of onion addresses after proposal 224 gets implemented Clarity is always a plus (: If the story is that people are remembering their shit, readability increases the probability of associative memory formation. Google search bar of browser Silly redundancy; why have two search bars next to each other q: to access [all the mails] x@y.z in the address bar has been known to prompt sign in. Searching can be a security tactic. Wordlife, Spencer ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
George Kadianakis: > this is an experimental mail meant to address legitimate usability concerns > with the size of onion addresses after proposal 224 gets implemented. It's > meant for discussion and it's far from a full blown proposal. Taking a step back here, I believe the size of the address to be a really minor usability problem. IPv6 adressses are 128 bits long, and plenty of people in this world now access content via IPv6. It's not a usability problem because they use a naming—as opposed to addressing—scheme to learn about the appropriate IPv6 address. While I do think we should think of nicer representation for the new addresses than base32, and we should adress that, working on a naming system sounds like an easier way out to improve onion services usability than asking people to remember random addresses (be them 16 or 52 characters-long). (I now plenty of people who type “riseup” in the Google search bar of their browser to access their mailbox… They don't even want to/can't remember an URL. Hardly a chance they will remember an onion address, whatever its size.) Maybe it would be worthwhile to ask the UX team for input on the topic? -- Lunar 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] prop224: Ditching key blinding for shorter onion addresses
whoops, didn't reply-all. On Sat, Jul 30, 2016 at 1:00 PM, Nick Mathewson wrote: > On Sat, Jul 30, 2016 at 9:32 AM, George Kadianakis > wrote: > [...] >> >> Please let me know in what way this scheme is completely broken! > > I think it has the same problem as the last one: there does not appear > to be a way to keep an attacker from putting their own record in place > using your query_key, and thereby performing a DoS on your hidden > service. > > > -- > Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
ban...@openmailbox.org writes: > [ text/plain ] > On 2016-07-29 17:26, George Kadianakis wrote: >> Hello people, >> >> this is an experimental mail meant to address legitimate usability >> concerns >> with the size of onion addresses after proposal 224 gets implemented. >> It's >> meant for discussion and it's far from a full blown proposal. >> >> Anyway, after prop224 gets implemented, we will go from 16-character >> onion >> addresses to 52-character onion addresses. See here for more details: >> >> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n395 >> >> This happens because we want the onion address to be a real public key, >> and not >> the truncated hash of a public key as it is now. We want that so that >> we can do >> fun cryptography with that public key. Specifically, we want to do key >> blinding >> as specified here: >> >> https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1692 >> > > > Speaking out of turn here: > > Why not integrate kernelcorn's OnioNS project and keep all the current > security properties? > > OnioNS addresses are much more user friendly than even the shorter > .onion addresses. Hello bancfc, AFAIK, the OnioNS project was never actually finished nor deployed. It also has various engineering/deployment issues that have not been addressed and it requires a whole infrastructure/community to work. In general, I'm open to DNS-like approaches for hidden services, but if we can also improve the UX situation on the protocol layer, that seems like a win to me :) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
Nick Mathewson writes: > [ text/plain ] > On Fri, Jul 29, 2016 at 11:26 AM, George Kadianakis > wrote: >> So basically in this scheme, HSDirs won't be able to verify the signatures of >> received descriptors. >> >> The obvious question here is, is this a problem? > > I'm not sure I fully understand, so here's a couple of quick questions > before I look more deeply. (I'm assuming that descriptors are indexed > by their ephemeral address here. If that's wrong and they're indexed > by something other than than ephemeral address, my analysis is wrong.) > > > 1) In your scheme, how does descriptor replacement work? In the > current scheme, if my introduction points change, I can upload a new > descriptor. In this scheme, it seems that either _anyone_ can upload > a new descriptor with the same ephemeral address (which is insecure), > or descriptors cannot be replaced (which is problematic). > > 2) Even if descriptors can't be replaced, there's still a problem: > What stops an attacker from racing the hidden service to try to upload > their own competing descriptor with the same ephemeral address? > Oops, you are absolutely right! :) Seems like security property (e) from the previous email was much more important than I thought! The HSDir must indeed be able to validate that a descriptor was signed using a particular ephemeral key (which then maps to a particular identity key). OK, here is another brainstormy attempt at shortening onion addresses post-prop224, while maintaining the same security properties: Can we use HSDirs to store encrypted identity keys for HSes, along with the encrypted descriptors? When clients query the HSDir, they fetch both the encrypted identity key and the encrypted descriptor, and use the former to decrypt the latter. Let me try to make this more formal by stating some definitions from prop224: A is the identity public key of the HS A_t is the ephemeral blinded key of the HS for time period t E(desc) is the encrypted HS descriptor using key H(t||A) exactly as in prop224 Now let's introduce some new notions: - onion_address = H(A || "onion_address") truncated to 128 bits onion_address is the string that clients need to know to connect to an HS. - query_key = H(onion_address || t || "query_key") query_key is used to query the HSDir for HS information. Specifically for the encrypted HS identity key and the encrypted descriptor of the HS. - encryption_key = H(onion_address || t || "encryption_key") encryption_key is used to encrypt the identity key A of the HS so that it's hidden from entities who don't know the onion_address (like HSDirs). - identity_key_ciphertext = E_encryption_key(A) identity_key_ciphertext is the identity key of the HS encrypted using encryption_key. Now for the protocol part: In current prop224, the HS uploads to the HSDir its ephemeral blinded key A_t, and its encrypted descriptor E(desc). That remains the same in this scheme, but the HS also uploads the query_key and identity_key_ciphertext to the HSDir. The HSDir verifies the descriptor signature as normal, and uses query_key as the index for all that information. Now, a client who wants to connect to that HS, uses the onion_address to derive the query_key, and sends query_key to the HSDir. The HSDir then checks its index, and returns to the client the encrypted descriptor E(desc) and also the identity_key_ciphertext. The client at this point derives encryption_key using the onion_address, and decrypts the identity_key_ciphertext. After the client does so, the client knows A and can decrypt and verify the descriptor ciphertext as normal. Does this make sense? The idea is that we use HSDirs for PKI along with descriptor storage. We basically encrypt the identity key of the HS using the onion_address and store it in the HSDirs. We never reveal onion_address to the HSDirs. Please let me know in what way this scheme is completely broken! (I've received many concerns about the future size of onion addresses, and hence I feel obligated to hit my head against the wall some more.) Cheers! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
On 2016-07-29 17:26, George Kadianakis wrote: Hello people, this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal. Anyway, after prop224 gets implemented, we will go from 16-character onion addresses to 52-character onion addresses. See here for more details: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n395 This happens because we want the onion address to be a real public key, and not the truncated hash of a public key as it is now. We want that so that we can do fun cryptography with that public key. Specifically, we want to do key blinding as specified here: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1692 As I understand it the key blinding scheme is trying to achieve the following properties: a) Every HS has a permanent identity onion address b) Clients use an ephemeral address to fetch descriptors from HSDir c) Knowing the ephemeral address never reveals the permanent onion address c) Descriptors are encrypted and can only be read by clients that know the identity onion key d) Descriptors are signed and verifiable by clients who know the identity onion key e) Descriptors are also verifiable in a weaker manner by HSDirs who know the ephemeral address In this email I'm going to sketch a scheme that has all above properties except from (e). The suggested scheme is basically the current HSDir protocol, but with clients using ephemeral addresses for fetching HS descriptors. Also, we truncate onion address hashes to something larger than 80bits. Here is a sketch of the scheme: -- Hidden service Alice has a long-term public identity key: A Hidden service Alice has a long-term private identity key: a The onion address of Alice, as in the current scheme, is a truncated H(A). So let's say: onion_address = H(A) truncated to 128 bits. The full public key A is contained in Alice's descriptor as it's currently the case. When Alice wants to publish a descriptor she computes an ephemeral address based on the current time period 't': ephemeral_address = H(t || onion_address) Legitimate clients who want to fetch the descriptor also do the same, since they know both 't' and 'onion_address'. Descriptors are encrypted using a key derived from the onion_address. Hence, only clients that know the onion_address can decrypt it. Descriptors are signed using the long-term private key of the hidden service, and can be verified by clients who manage to decrypt the descriptor. --- Assuming the above is correct and makes sense (need more brain), it should maintain all the security properties above except from (e). So basically in this scheme, HSDirs won't be able to verify the signatures of received descriptors. The obvious question here is, is this a problem? IIUC, having the HSDirs verify those signatures does not offer any additional security, except from making sure that the descriptor signature was actually created using a legitimate ed25519 key. Other than that, I don't see it offering much. So, what does this additional HSDir verification offer? It seems like a weak way to ensure that no garbage is uploaded on the HSDir hash ring. However, any reasonable attacker will put their garbage in a descriptor and sign it with a random ed25519 key, and it will trivially pass the HSDir validation. So do we actually care about this property enough to introduce huge onion addresses to the system? Please discuss and poke holes at the above system. Cheers! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev Speaking out of turn here: Why not integrate kernelcorn's OnioNS project and keep all the current security properties? OnioNS addresses are much more user friendly than even the shorter .onion addresses. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
On Fri, Jul 29, 2016 at 11:26 AM, George Kadianakis wrote: > So basically in this scheme, HSDirs won't be able to verify the signatures of > received descriptors. > > The obvious question here is, is this a problem? I'm not sure I fully understand, so here's a couple of quick questions before I look more deeply. (I'm assuming that descriptors are indexed by their ephemeral address here. If that's wrong and they're indexed by something other than than ephemeral address, my analysis is wrong.) 1) In your scheme, how does descriptor replacement work? In the current scheme, if my introduction points change, I can upload a new descriptor. In this scheme, it seems that either _anyone_ can upload a new descriptor with the same ephemeral address (which is insecure), or descriptors cannot be replaced (which is problematic). 2) Even if descriptors can't be replaced, there's still a problem: What stops an attacker from racing the hidden service to try to upload their own competing descriptor with the same ephemeral address? -- Nick ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] prop224: Ditching key blinding for shorter onion addresses
Hello people, this is an experimental mail meant to address legitimate usability concerns with the size of onion addresses after proposal 224 gets implemented. It's meant for discussion and it's far from a full blown proposal. Anyway, after prop224 gets implemented, we will go from 16-character onion addresses to 52-character onion addresses. See here for more details: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n395 This happens because we want the onion address to be a real public key, and not the truncated hash of a public key as it is now. We want that so that we can do fun cryptography with that public key. Specifically, we want to do key blinding as specified here: https://gitweb.torproject.org/torspec.git/tree/proposals/224-rend-spec-ng.txt#n1692 As I understand it the key blinding scheme is trying to achieve the following properties: a) Every HS has a permanent identity onion address b) Clients use an ephemeral address to fetch descriptors from HSDir c) Knowing the ephemeral address never reveals the permanent onion address c) Descriptors are encrypted and can only be read by clients that know the identity onion key d) Descriptors are signed and verifiable by clients who know the identity onion key e) Descriptors are also verifiable in a weaker manner by HSDirs who know the ephemeral address In this email I'm going to sketch a scheme that has all above properties except from (e). The suggested scheme is basically the current HSDir protocol, but with clients using ephemeral addresses for fetching HS descriptors. Also, we truncate onion address hashes to something larger than 80bits. Here is a sketch of the scheme: -- Hidden service Alice has a long-term public identity key: A Hidden service Alice has a long-term private identity key: a The onion address of Alice, as in the current scheme, is a truncated H(A). So let's say: onion_address = H(A) truncated to 128 bits. The full public key A is contained in Alice's descriptor as it's currently the case. When Alice wants to publish a descriptor she computes an ephemeral address based on the current time period 't': ephemeral_address = H(t || onion_address) Legitimate clients who want to fetch the descriptor also do the same, since they know both 't' and 'onion_address'. Descriptors are encrypted using a key derived from the onion_address. Hence, only clients that know the onion_address can decrypt it. Descriptors are signed using the long-term private key of the hidden service, and can be verified by clients who manage to decrypt the descriptor. --- Assuming the above is correct and makes sense (need more brain), it should maintain all the security properties above except from (e). So basically in this scheme, HSDirs won't be able to verify the signatures of received descriptors. The obvious question here is, is this a problem? IIUC, having the HSDirs verify those signatures does not offer any additional security, except from making sure that the descriptor signature was actually created using a legitimate ed25519 key. Other than that, I don't see it offering much. So, what does this additional HSDir verification offer? It seems like a weak way to ensure that no garbage is uploaded on the HSDir hash ring. However, any reasonable attacker will put their garbage in a descriptor and sign it with a random ed25519 key, and it will trivially pass the HSDir validation. So do we actually care about this property enough to introduce huge onion addresses to the system? Please discuss and poke holes at the above system. Cheers! ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev