On Wed, Oct 16, 2013 at 9:18 PM, George Kadianakis desnacked@riseup.net wrote:
Hey Nick,
these are my notes from when I was writing the HS blog post. I updated them a bit with some more stuff.
Might be helpful :)
Hi, George! Here's the list I came up with. Let's try to merge them, assuming I thought of anything you didn't. I'm also thinking of an initial commentary on some of your items below.
"""
SECURITY: * Ed25519 for all signatures, curve25519 for all handshake stuff. * Migrate identities to ed25519. * Enumeration resistance: hsdirs can't list what services they're serving. * Proper hybrid encryption for INTRODUCE2 cells. * Improved authorization systems. * Consider cost/benefit: At descriptor level, at INTRODUCE1, at INTRODUCE2, and RENDEZVOUS. * Try to support many distinct users by shared secret, by public key, by...? * Able to keep identity keys offline and generate keys as needed * Every part should be harder to DOS * Hard to predict which HSDirs will get used for a service. * All hybrid encryption done properly. * Separate guards for hidden service and for client use? * Make nearly everything less linkable to the other things. * Possibly, avoid having to store even public key on hidden service.
SCALING: * Allow a hidden service to be provided from multiple places somehow. * Obscure number of instances? * Avoid having a "master" instance without which the others can't function. * Obscure which instances are up/down? * Support more introduction points.
GUARDS: * Not completely related, but we should go over Roger's big laundry list of guard-related changes and actually make sure they happen.
PLUMBING: * ntor handshake in place of TAP handshake. support for future handshakes. * Support for future CREATE2 cell types. * Support for future EXTEND2 node specifiers * Support for future relay crypto revisions * Plan to deprecate older versions of the hs protocol. * Plan for support of bigger keys for forward-secrecy at least.
DOCUMENTATION: * replacement for rend-spec.txt * more clarity in security analysis """
"""
HS improvements:
Anything I'm not commenting on below I generally agree with.
1 performance 1.1 reuse IPs (#8239) 1.2 torperf (#8510)
Did you get the right bug number? That ticket doesn't mention #8510.
1.3 scaling https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html 1.4 valet nodes
Is this still useful given a cryptographic #8106 solution? The anti-enumeration part would seem to be taken care of. The anti-DoS part might be handy, or might deserve to get folded in somewhere else in the protocol.
1.5 lasse's "Improving Efficiency and Simplicity of Tor circuit establishment and hidden services" 1.5.1 big design change. maybe worth it. assumes valet nodes IIRC
I'm not so sure this is a win; a lot of the cryptography seems obsoleted by ntor. I'm not enthusiastic about onion encryption, either.
We should definitely go over both of those last two with a fine-toothed comb though, and see what we *do* want to use from them. Did something you saw there attract you?
2 security 2.1 Crypto upgrade 2.1.1 Upgrade id keys [https://lists.torproject.org/pipermail/tor-dev/2013-October/005536.html] [https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html] 2.1.2 Upgrade IP service keys 2.1.3 Fix hybrid encryption (?) 2.2 Onion anti-harvesting (#8106) https://lists.torproject.org/pipermail/tor-dev/2013-October/005534.html 2.3 Guard node enumeration (#9001) 2.3.1 Virtual Circuits? Guard tiers?
Important but IMO orthogonal.
2.4 Unpredictable HSDirs (#8244) 2.5 Hide HS popularity 2.5.1 Oblivious transfer for HSDirs (is it needed if we have #8106? maybe yes.)
I dunno; it's hard to do
2.5.2 Unlinkable introductions in IPs (is this even possible?) (do we even care? we have service keys)
Service keys limit the linkability here, I agree.
3 Can we decrease the responsibility of guard nodes? It seems that security of HSes == their guard nodes, atm. 3.1 Implement stuff from https://blog.torproject.org/blog/improving-tors-anonymity-changing-guard-par... 3.2 Add optional padding/bitrate anti-fingerprinting transport for HSes. 3.2.1 Can be enabled by truly paranoid HSes. 3.2.2 But this is going to make HSes stand out even more! 3.2.3 These transports can all be broken anyway. Except a truly slow but theoretically secure padding/constant bitrate transport.
This all seems orthogonal.
3.3 What are other anonymous publishing protocols doing here? I2P seems to be weak here too, according to Grothoff's recent paper.4 misc 4.1 HSDirs system 4.1.1 Do we still need the hash ring even after #8106?
I think so. If we went back to a few directories, they'd be an obvious DoS target, *and* they could censor any HS for which they knew the public key.
4.1.2 Look into Valet nodes 4.2 petnames/human memorable onions? 4.2.1 maybe better as a third party (probably unofficial) plugin to tor/firefox 4.3 Read and compare with other HS-like designs. See: 4.3.1 I2P, GNUNet, rewebber, retroshare, "Anonymizing censorship resistant systems" by Serjantov, ... 4.3.2 Check uni-directional tunnels of I2P and their pros/cons. 4.3.3 http://freehaven.net/anonbib/
Don't forget freenet and tahoe-lafs.
4.4 Encrypted servives https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-encrypted-services.txt
Somewhat orthogonal.
5 What else should we do? How would we design HSes if we were not prejudiced by the current design?
"""