Perhaps instead of just making it redundant, they should shut off at random times for random lengths (like 10 hours or less). From the way I understand the attacks remaining against tor, this would make is much more complicated to do a timing or deductive attack against the hidden service even for a global adversary. This would actually act to the disadvantage to a one-machine hidden service, but it would be a really good idea for a redundant one. Another question is how do we keep the wikis in sync without connecting to the other ones every time their is a change (which would make timing attacks much easier). Perhaps a linux machine that has a network-raid volume with the other servers (over tor) acting as sections of the RAID volume? Comrade Ringo Kamens
On 8/8/07, Karsten Loesing <[EMAIL PROTECTED]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > >> I like the distributed private key idea. > > Yes, that's really a nice idea. And it might even work. > > >> My question > >> is: what would determine which server got chosen? > > > > I think that if two or more hidden services used the same private key, > > thus the same .onion hostname, the master servers would always point > > to the latest updated. > > Correct. A hidden service uploads a current descriptor (containing > contact information) if a) there is some significant change in contact > information or b) an hour passes. > > > Then, they could, just to > > equal host usage, schedule tor restarts each 2 hours. So, in even > > hours host A would respond, and in pair hours host B would respond. > > And this, automatically. > > That's a bad idea, because it does not really improve availability if a > hidden service is restarted every two hours. > > The two services should rather be run in parallel all the time. Then, > after some maths, one would (probably -- am no mathematician) find that > both services have their own descriptors published half the time, and > thus receive half of the client accesses. (Note that the one-hour > intervals break as soon as the list of introduction points changes -- > that means that starting the nodes with a certain timing does not > significantly improve this solution.) > > However, I am quite sure that the developers did not have this variant > of content replication in mind when they designed the hidden services. > That means that it might break. But why not try it? :) > > - --Karsten > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFGuhxn0M+WPffBEmURAubmAJ9Or3XmcxgmnGxXJgDHGSXHPvaK5gCbB90/ > qeNETEE1FYc9bNxUeJi8niU= > =8nZG > -----END PGP SIGNATURE----- >