Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses

[Jeff Burdges]

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

[Jesse V]

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

[Jeff Burdges]

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

[George Kadianakis]

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

[U+039b]

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] 

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.)?

> 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

[z...@manian.org]

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

[Razvan Dragomirescu]

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

[Spencer]

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

[Lunar]

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

[Nick Mathewson]

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

[George Kadianakis]

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

[George Kadianakis]

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

[bancfc]

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

[Nick Mathewson]

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