[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Proposal of a new hidden wiki

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 <karsten.loesing@xxxxxxx> wrote:
> 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
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> iD8DBQFGuhxn0M+WPffBEmURAubmAJ9Or3XmcxgmnGxXJgDHGSXHPvaK5gCbB90/
> qeNETEE1FYc9bNxUeJi8niU=
> =8nZG