On Fri, 06 Aug 2010 12:35:44 -0400 Nathan Freitas <nathan@xxxxxxxxxxx> 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
Attachment:
signature.asc
Description: PGP signature