UPDATE
A description of the anon implementation I've been working on is below. I'm releasing this rough draft because the community wants it, but I will clean it up and present it properly with some charts after I get some rest 
Rough draft of anon implementation description, as requested by the community. Please note this is a work in progress, and there will be ongoing changes and revisions if issues are discovered.
Shieldcoin: Anonymous Coin Transaction Transfer MechanismTransferring data (encrypted keys) or files in a P2P network involves sending and recieving
data packets between computers on the internet. In typical P2P protocols, a peer connects
directly with other peers and gets a small part of the data from each. This involves many
computers which are unknown to each other but still identified by their IP address.
Determining which peers are serving data is simple, one just needs to add a peer to this
network and provide lots of data, and record the IP address of the machines that connect. The
direct connections between a client and the source is a weak point of security.
Shieldcoin aims to solve this problem by using explicit data connections only between trusted
wallets, which send encrypted verification messages to each other using signed SSL
certificates. These wallet connections are chained together to provide secure and anonymous
transfer tunnels across the whole Shieldcoin network. Each wallet will act as an anonymous
mixer, transferring and mixing coins between each other, with the outputs saved in an anonymous
and encrypted sidechain. This method will prevent classical IP spying techniques and more
advanced spying mechanisms based on man-in-the-middle attacks.
The anonymous routing model will allow wallets to exchange keys anonymously using tunnels. The
data is by nature re-encrypted as it passes through each pair of friends along the tunnel.
A, as a client requests data through trusted wallets only. The sources B and C and are not
known to A, and A is not known to them either.
The original idea was taken from the PhD thesis of Petr Matejka: Security in Peer-to-Peer
Networks [1].
An anonymous transaction request is performed by broadcasting a public key packet to all
connected wallets. The wallets forward it to other wallets, until the request is too old. If a
matching private key is found, a reply is send back by the inverse route that the request took.
If the request is too old and the destination wallet is not online, the request is archived in
a cache of public key broadcasts. The cache is examined each time a new request is received. If
already present, the request is discarded. An additional transfer fee will be added to
anonymous coin transfers to prevent spam attacks.
Shieldcoin tunnel establishment protocolTunnels are established using the same protocol as the anonymous transfers. A seperate cache is
used to store the tunnel requests, and route tunnel accept packets back to the original client.
The half-id of a tunnel request is a non reversible hash of the client SSL id, and the file
hash for which the tunnel will be used. It is salted by a session-dependent random number. Once
a peer responds to the tunnel request, it will merge this half-id with his own half-id, in a
non symmetric way to obtain the final tunnel id (Shieldcoin users see tunnels as “anonymous
tunnel 0x45eb7a34″. The ending number is the tunnel id). This means that:
tunnels between a given source and destination for a given hash, always have the same tunnel id
(although the tunnel request id changes every time) whatever the route they take;
the tunnel id is non symmetrical. This means that a tunnel from A to B for a given hash will
not have the same id than a tunnel from B to A for this hash;
from the half-id alone (resp. tunnel id), it is not possible to brute-force the requesting peer
id, because of the salting mechanism.
The second property is important because two peers might have two tunnels to each others for
the same transaction request going both ways. This happens when both peers are clients for a
hash that is swarming between multiple peers. The two tunnels might cross in between and their
ids should cause no ambiguity.
The tunnel protocols in Shieldcoin use no global addressing, as opposed to the original design
by Matejka [1]. Once established, a tunnel is always represented at each peer along the tunnel
by a pair of wallets. When data comes from one wallet, it is automatically forwarded to the
other wallet and vis versa.
Shieldcoin tunnel life handlingOne major difference between the implementation of tunnel network in Shieldcoin and the
original implementation described by P.Matejka in his thesis, is that tunnels in Shieldcoin do
not need additional management packets such as for closing a tunnel, or managing bandwidth.
Tunnels are removed from the list of existing tunnels by each peer when the traffic along the
tunnel is null for a definite period of time (60 seconds). This simple technique allows us to
robustly handle any incidental change of the network topology. If a tunnel is e.g. broken
because a peer disconnects, the tunnel will be removed by all other participating peers after
60 seconds, without the need to send a special tunnel closing packet.
From the point of view of the anonymous transfer send/recieving, each tunnel appears as just
another connected peer to which data chunks can be requested.
From the outside it is not able to read the data which is transferred between the Peers
(DarkNet). Because of the Authentication between the nodes, it should not be possible to use a
Man-in-the-middle Attack and log and manipulate the data-stream.
In an upcoming paper, I will treat the more technical aspects of the tunnel network and
anonymous transfer protocols - speed, anonymous transfer security in the case of rogue peers,
and other nasty algorithmic details.
Again, this paper and the ideas contained are a work in progress. There are some hurdles to
overcome, but I am working with a member of another open-source project which uses a similar
network tunneling method and making good strides.
Section 2:
Shieldcoin Distributed Chat SystemStill working on this part. I released this early because the community has been asking me to.
References:
[1] Safe and Private Data Sharing with Turtle: Friends Team-Up and Beat the System
Popescu, B.C. ; Crispo, B. ; Tanenbaum, A.S.
Proceedings of the 12th Cambridge International Workshop on Security Protocols, 2004
Show Posts
