Bitcoin Forum
June 23, 2024, 04:03:46 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Other / Archival / Re: Silk Road: anonymous marketplace. Feedback requested :) on: April 20, 2011, 07:39:53 AM
Actually, the vast majority of child porn is created by teenagers with camera phones.
Grin

Do you realy want to talk about CP? Do you realy know what CP is? Child Porn is not about two teenagers having sex, it is about adults raping kids (below 10 maybe).
Should everyone have the right to view/copy this stuff (without the approval of all performers)?


EDIT: @mvgdr (or whoever you are): My German teacher once said: "If you can't tell it short (summarised), you can't tell it." Please try to shorten up your posts, it is quite hard to read them.

Decentralized encrypted forum infrastructure on/over location hidden mix network with clearance based compartmentalization of posts/threads and each user controls their own contact list, no hierarchies or admins or mods.
2  Other / Archival / Re: Silk Road: anonymous marketplace. Feedback requested :) on: April 20, 2011, 07:04:09 AM
Were you thinking along the lines of a network of anonymous gpg identities, each participant signing the other's key and building a web of trust that can easily be transferred anywhere ASCII goes, so if one venue goes down the next can pop up with the survivors and still maintain much of the credibility of it's predecessor? It seems that this could be quite reliable if a simple framework where gpg was required to participate was implemented.

I think that's a great description of why the #bitcoin-otc web of trust is such a valuable tool for our community.

The project we are working on can be summarised as follows. The project is a decentralised forum at its heart, also working as an anonymity network. The project has a client side and a server side component, no browser will be required. It consists of both clients and servers, servers act as mixes. The goal is for it to be a location hidden mix net, meaning the actual mixes will be Tor hidden services. The sort of mixing utilised is known as Tau mixing. Tau mixing allows clients to determine a value for minimum crowd size and minimum time delay and apply these values to their messages. The mix nodes respect these values before forwarding the messages on. For example, a client may tag a post with Tau values of 'ten messages' and 'two hours'. The mix that receives this message will hold it until both ten messages have arrived and two hours of time have passed. I will not go into the technical analysis of Tau mixing here, however you can find papers on the subject at freehaven.

Messages are also padded with random data to obfuscate the sizing characteristics. Messages are encrypted with layers, each layer having random padding and Tau values in it as well as the hidden service URL of the next mix on the chain. This should prevent an attacker who can observe traffic into and out of a mix from linking messages in and messages out. The mixing will offer significantly more anonymity than is provided by Tor, as well as resistance to correlation attacks. As Tor is used on top of the mixing, it will act as a fail safe and further add anonymity.

Messages go through two stages, insertion and propagation. A message is anonymized via the insertion stage, going through multiple mixes with Tau values and layers of encryption and padding. After the message is anonymized it begins to propagate. This can be seen as more similar to Freenet, the encrypted message does not change from node to node while it propagates (ciphertext is the same from node A to node B) however layered link level encryption is provided by Tor. Messages are tagged with clearance levels as well. Key distribution for clearance levels is protected with asymmetric encryption.

The forum structure itself can be seen as more similar to instant message protocols than a regular forum. Each user has a buddy list with people on it who they invite. There are not administrators to invite people to the forum, rather people add each other to their buddy lists. When there are intersections between buddy lists, clearance levels can form. For example, perhaps Alice has Bob on her buddy list. Bob has Alice on his buddy list. Carol is also buddies with Bob and with Alice. This could be seen as a clearance level. Any of the three may make posts tagged for their shared clearance level. These posts will be encrypted with a key only the three of them posses. There is also no solid layout for the forum, rather posts can be tagged by the submitter with whatever layout they want. Bob could make a post with the tag :Subforum = Drugs - Clearance Level = ABC - Title = Drugs for sale!: . When Alice and Carol get this post, it will show up in a subforum called drugs client side. Perhaps Carol also has a clearance level with Doug and Earl. If Doug or Earl make a post :Subforum = Drugs - Clearance Level = CDE - Title = Drugs for sale!: the post will be merged into Dougs thread client side for Carol, although due to the clearance level Alice and Bob will not be able to obtain the ciphertext of the post or know the key to decrypt it even if they could. If a post is quoted and replied to, the reply inherits the clearance level of the quoted post at its basis, although members can be subtracted. Technically members can be added as well, but it would require a malicious client for this to happen and it unfortunately impossible to protect from.

When posts are obtained it is done via a single use reply block. If Carol wants new posts, she creates a return path to her as well as layer encrypted Tau values and keys. She can send this through out the network with requests for posts she is of an appropriate clearance for. The posts then travel down her reply path gaining a layer of encryption at each node, before they are stored on the final node on her path. She can now connect to this node via Tor, download all new messages, decrypt the layers of encryption and integrate the new posts she is cleared for into her client side forum structure.

We also have plans for compromise detection systems. These will use Shamirs secret splitting algorithm. Alice may have a package of drugs at a PO box obtained with fake identification. She can encrypt a message saying "I am leaving to pick up drugs from Bob, this should take me five hours". Now she splits the key to decrypt this message with shamirs secret splitting algorithm and sends the shares to five of her friends as well as the ciphertext of the message, instructions on where to rendezvous the shares and a countdown timer. If Alice is compromised at the PO box, she will not be able to disable the warning before the timer runs out and her friends can become suspicious of Bob. If Alice makes it back in time she can disable the timer and as long as X% of her friends respect her wish to not decrypt the ciphertext nobody will learn she worked with Bob.

We also have a PM system for communications. The forum uses strong encryption, RSA 4,096 bit asymmetric, serpent-256 symmetric. Authentication of posts can be obtained with RSA signatures if it is desired, however anonymous posting will also be supported (with in the set size of the clearance level). Public keys are stored signed over a distributed table to protect from MITM (X% of nodes must cooperate to present false keys, and clients can check their own keys anonymously, so the nodes do not know which key to spoof for which key request). No unencrypted data is ever on the nodes, only on clients that are cleared for it. There is no single server to take out to shut down the forum(s), rather it is a distributed network. Clients can also act as storage nodes for holding messages for other clients. Even finding the mixes/clients will require compromising Tor. We have steganographic protocols to hide the fact that our system is being used from the Tor nodes, although in the end Tor bridges will of course be required to hide that Tor is being used.

We are thinking of ways to implement a distributed trust system on top of this, so if Alice trusts Carol and comes into contact with Bob (who carol trusts) at some later date, she can know that Bob is trusted by Carol. This will indeed probably be based off web of trust. I am not sure if anyone here knows the websites Undrugged or Safe or Scam. They are closed database vendor review websites. If you know a vendors contact information, you can type it in and find reviews left on the vendor / leave reviews yourself. If you don't know the vendors contact information, you can not find it. We want to integrate features like this into our system as well, but make it distributed. If you know a vendors contact information, you can request reviews from the distributed network. If you don't know the vendors contact information, you can't find it. We can probably use some algorithm similar to the ones used to confirm shared secrets with OTR for this. This way a member of the network can show other nodes strings that give them no data if they do not already know a vendors contact information, but allow them to determine that there is a shared vendor if they already know the contact information, and then share reviews on the vendor.

This is just the basics but it is what we are working on, and I think it will be far superior to the centralized drug vending sites and much harder for law enforcement to compromise. We have one full time programmer working on this and expect an open source beta sometime in June. If anyone is interested in helping make it feel free to volunteer.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!