Re: Proposal of a new hidden wiki

["Josh McFarlane" <josh.mcfarlane@xxxxxxxxx>]

On 8/9/07, Ringo Kamens <2600denver@xxxxxxxxx> wrote:
> The way we were describing, by giving trusted servers the private key
> to make a redundant wiki system wouldn't have that problem unless on
> of the trusted servers gave away the key or got taken over by an
> adversary (police or what have you).

However, this still relies on detection of a compromised server. Say
an adversary silently compromises a server, and does not make it known
that they now have direct access to the private key. They can now
launch additional servers that connect into the distributed service
without any barriers. This is detected, and the private key is
changed. The compromised server admin, not realizing that his server
has been compromised, updates his key also. Then, the adversary has
the new key.

The method I proposed limits this affect, as any new servers need to
be indexed by the relevant wiki owners. If a server is compromised but
no data is tampered with, it doesn't matter since the compromised
server can only affect it's own service listings. Any wiki de-synching
could quickly get it removed from the listings on the other services
hosting the wiki.

> I actually thought about this a lot before the thread started. A
> standard installer CD for a customized linux distro could be made that
> when installed would ask for your hidden service private key. Then, it
> would have a small partition on a local, encrypted drive for apache,
> sql, and whatever else you would need which would (in the best
> situation) run off an external hard drive. Then you would have a
> network raid array that ran over tor, so when a wiki edit was made it
> was made to that raid array and everything would be updated, almost
> instantly. Does anybody see any potential problems there?
> Comrade Ringo Kamens

I think the biggest problem here is ensuring that it's not a password
security issue. Relying on the secrecy of the private key means any
compromise will have drastic affects on the service performance as a
whole. It might be better to try to come up with a solution that does
not rely on a shared secret private key.

The difficulty of updating with hosts with my solution could be easily
remedied with a tool that pulled from all the other hosts on your
current list and informed you of any new links. This way you could
easily review any suspicious links, and barring any detectable
compromise, add them in batches say once a week.

I think the distribution platform could also use some more discussion,
but I don't think this is going to be a Tor implementation issue, but
rather just finding the most effective method of live synchronized
changes. How do you plan on making a network raid array via the Tor
network?

-- 
Thanks,
Josh McFarlane
http://www.joshmcfarlane.com