Re: Proposal of a new hidden wiki
On Wednesday 08 August 2007 22:59:56 Ringo Kamens wrote: It's not the issue of a great wall attack where a person can't access a public wiki with onion links, it's an issue of whether that wiki could even exist. You'd have to crazy to host that on a public machine. Comrade Ringo Kamens You mean like these crazee boyz? http://eng.anarchopedia.org/Tor_network_links This is a useful link, could someone add it to the neat links section? signature.asc Description: This is a digitally signed message part.
Re: Proposal of a new hidden wiki
On 8/8/07, Ringo Kamens [EMAIL PROTECTED] wrote: I appreciate the concern, but I think that while freenet is a viable option and certainly there should be a backup on it, tor users need a central link cache (so they can use the tor hidden network). I think that tor is the right network for unbreakable hidden website, especially if we use redundant services (through RAID-over-network?). The reason we can do this on the real internet is that it would get censored. Really quickly. Many countries have laws banning such activities or linking to certain sites, like cryptography sites, which is why tor links must be linked to from a hidden wiki. The problem is setting up a system that is easy to replicate, but at the same time immune to attacks. If we attempted to implement an automated distributed service function, where you could have multiple sites under the same key, you'd have to have some method to prevent an attacker from simply launching a massive amount of sites under this key to destroy it. 1000 fake sites would cause probably cause the load balancer to refer to the fake sites the majority of the time, effectively take it off line. Perhaps the best way to do a distributed service like this would be to allow it to have a list of sites that it allows to substitute for itself. So, if three people wanted to host the Wiki, they would first have to set up a method to keep all 3 wikis current. Then, all three could launch their wikis. After the service was operational, they could update their service definition with 'links' to the other 2 services. Anytime someone requested one of the services, it would randomly choose between any of the listed. This would require the least amount of change but allow a basic multiple-backend service to go up without allowing it to be compromised by an attacker. One could argue that you could also put the replication into Tor, but I think that may be too complex to integrate directly. Any ideas / comments? -- Thanks, Josh McFarlane http://www.joshmcfarlane.com
Re: Proposal of a new hidden wiki
you'd have to have some method to prevent an attacker from simply launching a massive amount of sites under this key to destroy it. 1000 fake sites would cause probably cause the load balancer to refer to the fake sites the majority of the time, effectively take it off line. 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). 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 On 8/9/07, Josh McFarlane [EMAIL PROTECTED] wrote: On 8/8/07, Ringo Kamens [EMAIL PROTECTED] wrote: I appreciate the concern, but I think that while freenet is a viable option and certainly there should be a backup on it, tor users need a central link cache (so they can use the tor hidden network). I think that tor is the right network for unbreakable hidden website, especially if we use redundant services (through RAID-over-network?). The reason we can do this on the real internet is that it would get censored. Really quickly. Many countries have laws banning such activities or linking to certain sites, like cryptography sites, which is why tor links must be linked to from a hidden wiki. The problem is setting up a system that is easy to replicate, but at the same time immune to attacks. If we attempted to implement an automated distributed service function, where you could have multiple sites under the same key, you'd have to have some method to prevent an attacker from simply launching a massive amount of sites under this key to destroy it. 1000 fake sites would cause probably cause the load balancer to refer to the fake sites the majority of the time, effectively take it off line. Perhaps the best way to do a distributed service like this would be to allow it to have a list of sites that it allows to substitute for itself. So, if three people wanted to host the Wiki, they would first have to set up a method to keep all 3 wikis current. Then, all three could launch their wikis. After the service was operational, they could update their service definition with 'links' to the other 2 services. Anytime someone requested one of the services, it would randomly choose between any of the listed. This would require the least amount of change but allow a basic multiple-backend service to go up without allowing it to be compromised by an attacker. One could argue that you could also put the replication into Tor, but I think that may be too complex to integrate directly. Any ideas / comments? -- Thanks, Josh McFarlane http://www.joshmcfarlane.com
Re: Proposal of a new hidden wiki
On 8/9/07, Ringo Kamens [EMAIL PROTECTED] 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
Re: Proposal of a new hidden wiki
I just googled for raid over network, but I didn't find anything so maybe I made it up? How about a http://en.wikipedia.org/wiki/Storage_area_network? This still wouldn't fix the problem of a server going to the dark side but it would probably be a bit more practical. I have heard of YaCy which is a distributed search engine and I think there's at least one active node indexing tor. Is there any program like YaCy that would generate link directories? Comrade Ringo Kamens On 8/9/07, Josh McFarlane [EMAIL PROTECTED] wrote: On 8/9/07, Ringo Kamens [EMAIL PROTECTED] 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
Re: Proposal of a new hidden wiki
On 8/9/07, Ringo Kamens [EMAIL PROTECTED] wrote: I just googled for raid over network, but I didn't find anything so maybe I made it up? How about a http://en.wikipedia.org/wiki/Storage_area_network? This still wouldn't fix the problem of a server going to the dark side but it would probably be a bit more practical. I have heard of YaCy which is a distributed search engine and I think there's at least one active node indexing tor. Is there any program like YaCy that would generate link directories? Comrade Ringo Kamens The problem with a SAN is that it is a central storage site. Give a server write access and if they get compromised the entire Wiki would be gone. What if we set up some sort of communication system that 'informed' the other wiki sites on the access list to changes made? Then, if a site is compromised, all the transactions posted to it simply post to the other wiki's and can be rolled back, and no one has direct control over the other wiki mirrors. If a wiki owner thinks a site has been compromised, they can simply remove the site from their list of approved wiki-mirrors. YaCy works differently than what we want. They distribute their results across multiple machines, and do not mirror the data. What we are aiming to achieve is a service that appears to be one wiki but is indeed interconnected across many machines, each with it's own copy but changes are reflected across the entire set. This way, if one machine dies it does not affect service at all. If we do the YaCy method, if one machine is compromised, whatever data hashed to that server is lost forever. I really think any solution that we want to implement needs to have a mirror-based setup with each individual host (or groups of hosts) able to provide the entire wiki on it's own. -- Thanks, Josh McFarlane http://www.joshmcfarlane.com
Re: Proposal of a new hidden wiki
Hello all, I've been watching this discussion with some interest. It's an intriguing problem you are working on. Anyways, I was just wondering.. would it not be possible to use a custom configured/hacked version of Freenet that the nodes were their own micro Freenet and not connected to the regular Freenet? just a thought. Freemor [EMAIL PROTECTED] Freemor [EMAIL PROTECTED] This e-mail has been digitally signed with GnuPG See: http://gnupg.org/ for more details signature.asc Description: This is a digitally signed message part
