Thus spake Nathan Freitas (nathan@xxxxxxxxxxx): > Is transport or message layer encryption redundant between a tor client > and a hidden service? The short answer is yes, we believe it is redundant and unnecessary. The long answer is "My god man, hidden services? Nobody touches that code. Who knows what lurks in the deep..." In particular, the Tor Hidden Service protocol for some reason discounts the threat of hash collisions, opting for 80bit hashes for "usability" reasons in onion urls. These urls are the only real means a user has of authenticating their destination. In an ideal world, users are perfectly capable of memorizing every character of the 80bit base64 key hash in the .onion url. 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. There was a program called 'shallot' which optimized hidden service key generation to accomplish exactly this using THC's Fuzzy Fingerprint technique. It seems to exist only in rumor and legend these days, but if you would like an arbitrary snapshot of the code that calls itself 0.0.1, I can post it somewhere. It was originally created for the sake of creating vanity .onion urls. However, the author optimized it far enough so that the hash could have something like 8 characters in common with a target .onion url, in either the prefix, or the suffix, or both, with just a few machine-days of computation. Their implementation also only created "strong" RSA keys for the resulting .onion urls. If they allowed weak key generation for their targets, much more optimization was possible (and if your goal is to deceive a user into visiting or chatting with your spoofed hidden service, why not use weak keys?). So, while in theory, hidden services are probably just barely beyond the horizon of the cryptographically insecure, in practice they are a usability nightmare to use for things like chat, where humans need to establish visual continuity for the endpoint they are communicating with. Sadly, this issue may just be the tip of the iceberg in the hidden service design, and there may be other edge cases that could be a huge problem for uses like chat. Denial of service conditions are particularly susceptible to gaming for chat, and the hidden service code may have quite a few of those. "Oh, I'm sorry, my .onion is down because of reason X. It will never come back. This my new .onion. I made them as similar looking as possible for security reasons. Trust me." In an ideal world, we'd have a distributed dictionary that safely maps full-strength hidden service key hashes to unique, human readable names, a-la .i2p eepsites to avoid lookalikes and gaming. 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. All that said, hidden services do have one signifcant advantage over regular Tor usage that is probably worth mentioning: Hidden services overall are generally more secure than using Tor to contact an arbitrary Internet endpoint using an arbitrary application. This is due to the likelyhood of user error in the form of using insecure, non-torrified applications. Given the choice between an insecure app that has every feature that they want, and an secure app that is missing a feature or two, the average user will choose the insecure app *every* time, and recommend it eagerly to their friends. Hidden services at least have the advantage that they tend to be harder to connect to in a fashion that is insecure. Either they work, or they don't. Especially if you trust the hidden service you are attempting to connect to. > We are working on a simple "p2p" messaging service between Android > devices running Tor, with each running a hidden service to accept > messages. I am trying to figure out if we need to OTR or SSL on top of > this for any reason. Have you seen torchat? https://code.google.com/p/torchat/ I've not used it, but perhaps it could be worth looking at, at least. > I am just trying to understand how far we should rely on encryption with > the Tor stack for this type of thing, vs. adding in our own bits (err, > bytes). Probably your primary threat at this point is user error, more so than interception or the direct subversion of the hidden service protocol, which most likely is end-to-end secure... If your secondary crypto system could somehow improve upon the utterly broken usability model of hidden services, then it would be a good idea to add it. Most likely though, a secondary system would just add confusion, and therefore insecurity. Ultimately it depends on the userbase and the UI design. -- Mike Perry Mad Computer Scientist fscked.org evil labs
Attachment:
pgplYqORg3GLq.pgp
Description: PGP signature