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 :)
"""
HS improvements:
1 performance 1.1 reuse IPs (#8239) 1.2 torperf (#8510) 1.3 scaling https://lists.torproject.org/pipermail/tor-dev/2013-October/005556.html 1.4 valet nodes 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 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? 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.) 2.5.2 Unlinkable introductions in IPs (is this even possible?) (do we even care? we have service keys) 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. 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? 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/ 4.4 Encrypted servives https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-enc... 5 What else should we do? How would we design HSes if we were not prejudiced by the current design?
"""
Hey George,
Thanks for sending this to the list.
On Thu, Oct 17, 2013 at 02:18:01AM +0100, George Kadianakis wrote:
3.3 What are other anonymous publishing protocols doing here? I2P seems to be weak here too, according to Grothoff's recent paper.
Do you have a link? I found [0] but want to make sure this is the one to which you're referring.
[0] http://grothoff.org/christian/i2p.pdf
Thanks!
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?
"""
Nick Mathewson nickm@torproject.org writes:
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 nodesIs 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 IIRCI'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.
What about mirroring HS descriptors to all directory servers (or a big subset of them), similar to how it's done for normal directory documents?
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 server. - 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).
Here are my thoughts regarding why merging the Hidden Service directory system and regular directory system is a bad idea.
It would mean each directory server effectively has a list of every hidden service in the network. This may or may not be an issue if the descriptors are encrypted.
Additionally you could clog up the directory servers (potentially causing a DoS situation) by publishing massive quantities of hidden service descriptors. This may already be possible with router descriptors, however, I'm not sure; do directory servers store an arbitrary number of router descriptors from the same IP?
Since directory servers don't tend to change they would appear responsible for each hidden service, opening up the possibility of lawyer attacks => "we demand you stop hosting descriptors for this criminal hidden service", or "you have been aiding criminals by serving this hidden service's descriptors". Also, since they don't change it would be far more worthwhile for an adversary to try to attack or subvert them. The moving-target system that is currently in place is far stronger against these types of attacks.
Lastly since the hidden service will be establishing a circuit to each directory server periodically it may be possible to perform statistical attacks such as a predecessor attack against it. This isn't an issue with router descriptors since the onion routers aren't trying to be anonymous, but it is an issue with hidden service descriptors.
On Sun, Nov 10, 2013 at 9:19 PM, George Kadianakis desnacked@riseup.net wrote:
Nick Mathewson nickm@torproject.org writes:
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 nodesIs 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 IIRCI'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.
What about mirroring HS descriptors to all directory servers (or a big subset of them), similar to how it's done for normal directory documents?
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 server.
- 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).
tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Kang td66bshwu@gmail.com writes:
Here are my thoughts regarding why merging the Hidden Service directory system and regular directory system is a bad idea.
Thanks for your thoughts.
I'm also unsure on whether ditching the hash ring system is a good idea, but here are some comments on your thoughts:
It would mean each directory server effectively has a list of every hidden service in the network. This may or may not be an issue if the descriptors are encrypted.
This should not be an issue when #8106 is implemented. We should only ditch the hash ring after #8106 gets implemented.
Additionally you could clog up the directory servers (potentially causing a DoS situation) by publishing massive quantities of hidden service descriptors. This may already be possible with router descriptors, however, I'm not sure; do directory servers store an arbitrary number of router descriptors from the same IP?
AFAIK, this should also be possible with the current state of HS descriptor publishing.
Since directory servers don't tend to change they would appear responsible for each hidden service, opening up the possibility of lawyer attacks => "we demand you stop hosting descriptors for this criminal hidden service", or "you have been aiding criminals by serving this hidden service's descriptors". Also, since they don't change it would be far more worthwhile for an adversary to try to attack or subvert them. The moving-target system that is currently in place is far stronger against these types of attacks.
IANAL, so I can't really comment on this point.
Still, it seems to me that even with the current hash ring system, someone can accuse HSDirs for hosting descriptors of an HS for the current time period. Till #8244 is solved, they can even accuse future HSDirs.
Lastly since the hidden service will be establishing a circuit to each directory server periodically it may be possible to perform statistical attacks such as a predecessor attack against it. This isn't an issue with router descriptors since the onion routers aren't trying to be anonymous, but it is an issue with hidden service descriptors.
This is worth thinking about. However, even with the current situation, Hidden Services periodically establish circuits to their HSDirs, so I'm not sure if ditching the hash ring will make any difference.
AFAIK, this should also be possible with the current state of HS descriptor publishing.
It should be possible, yes, but it's not a serious problem due to the decentralised nature of hidden service descriptor publishing. On the other hand I'm under the impression that there's only a few directory servers and that they're critical to the operation of the Tor network, so this would become and issue if directories were used instead. You could potentially cripple the whole network.
Till #8244 is solved, they can even accuse future HSDirs.
That's a good point, actually. It would be more labour intensive to contact future HSDirs, but you could and it would produce the same result.
This is worth thinking about. However, even with the current situation, Hidden Services periodically establish circuits to their HSDirs, so I'm not sure if ditching the hash ring will make any difference.
It would make a difference because currently HSDirs change every 24 hours or so. If directory authorities were used as HSDirs instead they would (probably) be used indefinitely.
On Tue, Nov 12, 2013 at 12:11 AM, George Kadianakis desnacked@riseup.net wrote:
Kang td66bshwu@gmail.com writes:
Here are my thoughts regarding why merging the Hidden Service directory system and regular directory system is a bad idea.
Thanks for your thoughts.
I'm also unsure on whether ditching the hash ring system is a good idea, but here are some comments on your thoughts:
It would mean each directory server effectively has a list of every hidden service in the network. This may or may not be an issue if the descriptors are encrypted.
This should not be an issue when #8106 is implemented. We should only ditch the hash ring after #8106 gets implemented.
Additionally you could clog up the directory servers (potentially causing a DoS situation) by publishing massive quantities of hidden service descriptors. This may already be possible with router descriptors, however, I'm not sure; do directory servers store an arbitrary number of router descriptors from the same IP?
AFAIK, this should also be possible with the current state of HS descriptor publishing.
Since directory servers don't tend to change they would appear responsible for each hidden service, opening up the possibility of lawyer attacks => "we demand you stop hosting descriptors for this criminal hidden service", or "you have been aiding criminals by serving this hidden service's descriptors". Also, since they don't change it would be far more worthwhile for an adversary to try to attack or subvert them. The moving-target system that is currently in place is far stronger against these types of attacks.
IANAL, so I can't really comment on this point.
Still, it seems to me that even with the current hash ring system, someone can accuse HSDirs for hosting descriptors of an HS for the current time period. Till #8244 is solved, they can even accuse future HSDirs.
Lastly since the hidden service will be establishing a circuit to each directory server periodically it may be possible to perform statistical attacks such as a predecessor attack against it. This isn't an issue with router descriptors since the onion routers aren't trying to be anonymous, but it is an issue with hidden service descriptors.
This is worth thinking about. However, even with the current situation, Hidden Services periodically establish circuits to their HSDirs, so I'm not sure if ditching the hash ring will make any difference. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Kang td66bshwu@gmail.com writes:
AFAIK, this should also be possible with the current state of HS descriptor publishing.
It should be possible, yes, but it's not a serious problem due to the decentralised nature of hidden service descriptor publishing. On the other hand I'm under the impression that there's only a few directory servers and that they're critical to the operation of the Tor network, so this would become and issue if directories were used instead. You could potentially cripple the whole network.
Hm. I think we are thinking of different schemes.
I was discussing the possibility of normal directory servers caching and serving the HS descriptors. (The Hidden Services would upload their descriptors to the directory authorities and then the directory servers would fetch the descriptors from the authorities.) It is my impression that this is how the current directory system works.
Although, it's true that this puts more trust and network load to the authorities.
Till #8244 is solved, they can even accuse future HSDirs.
That's a good point, actually. It would be more labour intensive to contact future HSDirs, but you could and it would produce the same result.
This is worth thinking about. However, even with the current situation, Hidden Services periodically establish circuits to their HSDirs, so I'm not sure if ditching the hash ring will make any difference.
It would make a difference because currently HSDirs change every 24 hours or so. If directory authorities were used as HSDirs instead they would (probably) be used indefinitely.
-
George Kadianakis -
Kang -
Matthew Finkel -
Nick Mathewson