[tor-dev] Discussion on the crypto migration plan of the identity keys of Hidden Services

[Mike Perry]

adrelanos:
> George Kadianakis:
> > If we move to the higher security of (e.g.) 128-bits, the base32 string
> > suddenly becomes 26 characters. Is that still conveniently sized to pass
> > around, or should we admit that we failed this goal and we are free to
> > crank up the security to 256-bits (output size of sha-256) which is a 52
> > character string?
> 
> In doubt: if possible, maintainable, not too much work, you name it...
> When having the less secure version as default, please let the hidden
> service hosts decide if they want to use the more secure version by
> using an option.
> 
> I don't know if the petname system is an completely orthogonal issue or
> if it could be considered when you decide this one.
> 
> >> Or have an option for maximum key length and a weaker default if common
> >> CPU's are still too slow? I mean, if you want to make 2048 bit keys the
> >> default because you feel most hidden services have CPU's which are too
> >> slow for 4096 bit keys, then use 2048 bit as default with an option to
> >> use the max. of 4096 bit.
> >>
> >> Bonus point: Can you make the new implementation support less painful
> >> updates (anyone or everyone) when the next update will be required?
> >> (forward compatibility)
> > 
> > I was also trying to think of a solution to this problem, but I failed.

I think you were heading in the right direction with the petname idea.
What if we deployed a potentially shitty naming layer that "probably"
won't break within the next 6-12 months, but *might* last quite a bit
longer than that, for backward compatibility purposes.

This naming layer could allow interested parties to sign registration
statements using their current onion key with an expiration time,
satisfying our deprecation desires for the 80 bit name. If the naming
layer actually survives without visible compromise until that point, we
could allow it to store signed statements about translations between the
new keys and their desired name (first-come, first-serve; names are
reserved for N months until resigned).

A more specific version of this question is: How readily could we hack
Namecoin or some other similar consensus-based naming system[1] into
Tor?

Such a mechanism would obviously provide enumeratability for hidden
services that chose to use it, but hopefully it would be optional: you
can still use IP addresses in browsers, after all.


In terms of verification, it would be trivial to alter the browser UI to
display the actual key behind the hidden service (ie: through a control
port lookup command and some kind of URL icon that varied depending on
consensus naming status).

We could also provide a hacked version of CertPatrol that monitors the
underlying public keys for you, and it would also be relatively easy to
add a "second-look" authentication layer through the HTTPS-Everywhere
SSL Observatory, similar to what exists now for SSL public keys.

In fact, if we can agree on a solid consensus-based naming scheme as a
valid transition step, I think it is worth my time to let the rest of
the browser burn while I implement some kind of backup authentication +
UI for this. After all, memorable hidden service naming would be a
usability improvement.


Should we try it? 

The major downside I am seeing is PR fallout from the hidden services
that chose to use it.. They might be a unrepresentative subset of what
actually people need hidden services for. I think the real win for
hidden services is that we can turn them into arbitrary private
communication endpoints, to allow people to communicate in ways that do
not reveal their message contents *or* their social network. There
probably are other uses whose promise would be lost in the noise
generated from this scheme as well...



1. https://en.wikipedia.org/wiki/Namecoin.

We don't have to choose Namecoin, though. Another alternative is for the
dirauths to add a URI for an "official" naming directory file as a
parameter in the consensus consensus, and also provide its SHA256/SHA-3.
A flatfile might be less efficient than Namecoin in terms of storage and
bandwidth requirements, though. It's probably also easier to censor
(unless it is something like a magnet link).

For all you Zooko's Triangle[2] fans: The Namecoin mechanism attempts to
"square" the triangle with a first-come first-serve distributed
consensus on the pet names document, but still fall back to
"Secure+Global" at the expense of "Memorable". The interesting bit is
that in this case, the browser UI can help you on the "Memorable" end,
should the consensus mechanism fail behind your back.

2. https://en.wikipedia.org/wiki/Zooko%27s_triangle



-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20130517/38047faa/attachment.pgp>