[tor-dev] Notes on HS revamping
desnacked at riseup.net
Sun Nov 10 10:49:09 UTC 2013
Nick Mathewson <nickm at torproject.org> writes:
> On Wed, Oct 16, 2013 at 9:18 PM, George Kadianakis <desnacked at 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.
> * 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,
> * 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.
> * 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.
> * Not completely related, but we should go over Roger's big laundry list of
> guard-related changes and actually make sure they happen.
> * 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.
> * 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,
> 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
>> 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-parameters
>> 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.
What about mirroring HS descriptors to all directory servers (or a big
subset of them), similar to how it's done for normal directory
Drawbacks here include:
- Directory servers will have to store _many_ HS descriptors. Let's
say that the size of an HS descriptor is 1kb and we have 100k Hidden
Services, then there will be a 100MB overhead for each HS directory
- Since each DS will store all the HS descriptors, it will have a
rough idea of the number of HSes in the network.
Positive changes are:
- We can simply forget all the hash ring code.
- We don't have to solve #8244.
- HSes become much harder to DoS on the HSDir-layer.
- HS directory requests for popular services spread through the whole
network, not just through the 6 HSdirs.
More thinking needs to be done here. Especially to see if "mirror HS
descriptors to all directory servers" scales (I would not be surprised
if it doesn't).
More information about the tor-dev