Encryption over Hidden Services

[Robert Ransom]

On Fri, 06 Aug 2010 12:35:44 -0400
Nathan Freitas <nathan at freitas.net> wrote:

> - Currently, to get "push" updates, a mobile device has to either poll,
> keep a socket open, or receive some sort of SMS or other network native
> push. With a hidden service, we can hold a server socket open on the
> device, and let Tor handle the inbound traffic.

That sounds like a bad idea.  If you use only one hidden service per
device, an attacker can easily direct a ‘special’ update to a specific
user.  If you use two or more hidden services per device and dedicate
one of them to receiving updates, it's still possible for a well-funded
attacker to correlate a device's hidden services (their descriptors
will always be published at about the same time), and you're putting
more load on the hidden-service directories for a lousy reason.

What's wrong with ‘pull’ updates, anyway?  Everyone else uses them.

> > In the real world, it is disturbingly practical to compute .onion urls
> > that have a significantly large number of characters in common with an
> > arbitrary target url, in arbitrary positions of the url.
> 
> We would never do this... our focus is not on the hidden service web so
> to speak, and more on the hidden service as infrastructure for
> messaging. This removes a ton of issues around friendly URL schemes.

It doesn't matter whether you would do that -- an attacker can generate
keys whose hashes match 7 characters at the beginning and 2 at the end
of your hidden service name (and as coderman pointed out, this will
take any competent TLA very little time), and your users will not check
the rest of the hash.  DO NOT rely on your users comparing a key
fingerprint with any care at all.

> > In the real world, secure distributed dictionaries for this may not
> > exist, and/or may have subtle vulnerabilities of their own. They probably
> > do exist for our centralized directory model, but we haven't really
> > devoted enough thought into the hidden service design to really bother
> > with them. Perhaps you could build one as part of your chat protocol.
> 
> Would love to, with some help. We have initially been thinking about a
> centralized directory server, a basic DNS type service, mapping
> nicknames to .onions. This would be optional.

Yes, centralize it!  That way, the ‘very polite man from Italy named
Guido’ that Mr. Dingledine keeps mentioning in the Tor videos can
arrange a spoofed directory entry with only one, er, visit.

Why not require your users to exchange their contact addresses in
advance using ordinary Internet mail messages or attachments?  That
makes spoofing a name-hash association at least slightly harder, and
also increases the difficulty of spamming your entire userbase.


Robert Ransom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20100806/52aaeafc/attachment.pgp>