AnonNet: Anonymous Network Project

November 3, 2003: While working on another project made a stupid mistake w/ pointer arith and the sizeof operator (honestly, I don't think this is another one of those `this is why not to use C' things :P) Decided to grep for it in the AnonNet src and found one instance of it in the packet code again. Even more improvement (longer mean time between failure), though there is still something lingering.

July 2, 2003: Hopefully discovered and squashed the out-of-order packet bug. A packet wasn't being removed from a list before being put onto an out queue. Because of the way the packets were being traversed, the list pointers directed the traversal of one list to jump to another list. I had suspected such a mis-use of the list library, and have looked for errorneous list traversals before, but apparently missed this one. I believe that there is one more hard to find bug left (that easily manifests itself), which shows as wrongly decrypted packets, seemingly at the link layer.

April 27, 2003: working on lots of other stuff, including Watch. Finally came back to try to tackle the elusive packet corruption bug. Trying to use valgrind on an x86. Unfortuntely, it doesn't seem to like my optimizations setting used to build glibc on Gentoo Linux.

LinuxFund.org This notice is long overdue, but LinuxFund.org generously sent me a grant this summer. Aside from being an impetus for me to re-commit to AnonNet, I put some of it toward an Aspen Systems Alpha-633 deal on eBay ($225!). This will replace the current ailing server some friends and I lease at FastServers.Net (we'll co-lo w/ these guys), and anybody who could utilize some modest resources (AnonCVS, shell, tool-chain, etc) for a free software project, please e-mail me.

December 2, 2002: thought i found the packet mangler bug. there might have been contention between node_loop() and node_connect_async() sending multiple-packets, but i guess not 'cause the bug still lurks. *sigh*

November 28-29, 2002: fixed double-free from a typo in link_unpeer(). fixed dead-lock in link_poll() and LINK_SIGNAL(). things are running smoothly, but i think there's a another padding issue, this time at the link layer (i.e. null packets are causing the ends to begin encrypting/decrypting asynchronously). once this is ironed out, then that should be it for setting up a link across 5 nodes (it's working now, but when you stress the daemon w/ multiple debugging runs simultaneously most will start to fail from this link issue, tho happily all resources are now freed properly when things go awry). the debugging runs can now be set-off from a SIGTSTP (^Z) when the --debug flag is given.

November 25, 2002: This past weekend support has been added to keep null packets flowing while each node does it's logical operations. This is critical so that each end of the pipe keeps data flowing constantly, and we don't rely on the link layer to feign a full stream. However, the null-filling is causing problems w/ synchronizing streams after a caller and node have done the key exchange; there could be null packets coming down the pipe that weren't encrypted because when they were sent the key exchange was in progress, but was completed in mid-transit. Also, this has exposed some other channel processing bug. Anyhow, back to work....

The Anonymous Network Project is attempting to help establish an infrastructure for anonymous networking. Put simply, it dynamically builds a route between multiple "proxies" across the Internet, such that it would be extremely difficult for any party aside from yourself to determine the originator (you) of the traffic flowing over that route. In a nutshell, it prevents people or devices from spying on you, either actively or passively.

AnonNet is based on the PipeNet model. So is the Freedom Network and the Onion Routing project. KNet keeps a comprehensive list of anonymity projects.

AnonNet has 4 major goals:

  1. Strong Anonymity: The gauge is how closely AnonNet can implement the PipeNet model. A theoretical PipeNet could provide perfect anonymity.
  2. De-centralization: Everything must be distributed and have no necessity for the centralization of any of its dependent functions. This characteristic is variously referred to as a distributed network, or peer-to-peer network.
  3. Community: It is designed to be hosted broadly and accessible to all. This means the client facing functions should scale from a user on a 28.8/33.6 dial-up connection to T3 users. Just as important, it should be cheap on system resources, and especially on bandwidth costs, to make community hosting of reliable AnonNet nodes less burdensome.
  4. Interoperability: AnonNet should work with most major Internet applications such as the WWW, FTP, and e-mail (SMTP, POP, IMAP). Using traditional proxy servers, and neat libraries such as tsocks and SocksCap, most Internet software applications should be supported.

How does AnonNet compare to other consumer "anonymizing" services? One of the more popular services is Anonymizer.com. The problem w/ this service is that if I wanted to see who was using this service to view www.xyz.org, I could simply watch the Internet traffic coming and going from the Anonymizer service and pin-point who is doing what. Also, Anonymizer.com is centralized (in other words, the service is provided from a specific set of addresses on the Internet). Some countries, and many corporations, block access to Anonymizer.com, as well as to many similar services. AnonNet is designed to resist "black-listing", similar to how the Gnutella network resists the threats that affected Napster's demise.

It is important to note that all anonymizing services and applications are susceptible to traffic anaylsis, part of which is what was described above. AnonNet, and others based upon the Pipenet model, or similarly the Mix-net model, fair far better than any other service or application. Some services try to play keep-away w/ your traffic by simply bouncing data across the network in an attempt to obscure it. From a pure anonymity stand-point these schemes do not stand-up to scrutiny very well. One of the strongest techniques in AnonNet is the implementation of padding, which defends against timing analysis. AnonNet and the Freedom Network are the only applications I know of that implement any kind of padding, therefore every other anonymity application unduly exposes you to attack via timing analysis. And given the current state of the public TCP/IP network topology (i.e. large proportions of traffic traversing the same lines), plus the gains gotten from targeted attacks, timing analysis is a serious threat to anonymity, especially in the face of wider P2P application deployment where timing analysis will become a more valuable tool in general.

The main consideration is to remember that confidentiality is a component within anonymity, but not vice-versa. Strong crypto, but weak or trivial communication links, does not an anonymity application make. Just like secrecy in cryptography is not of much value in the creation and use of primitives, secrecy and obfuscation is not of much value in keeping people from tracing your steps.

AnonNet has been developed on Debian GNU/Linux (Woody/3.0) and OpenBSD 2.9/3.0. I have not tried to build or run it on anything else yet, but it is being written with portability in mind. The code strives to be ANSI/ISO Standard C compliant, and where possible only use generally adopted and standardized POSIX and UNIX X/Open routines. YMMV.

AnonNet requires GMP to provide multi-precision math for the public-key crypto implementations, and either a non-blocking [psuedo-]randomness device (eg. /dev/urandom) or a non-blocking, socket-based psuedo-randomness generator such as PRNGD. Regards to the following projects from which source was merged into AnonNet:

AnonNet is licensed under the GNU GPL, with (3rd party) portions utilizing the GNU LGPL and BSD-style licenses.

For more information, please refer to the source. A preliminary protocol specification is laid out in anonnet/PROTOCOL. The C source code also contains documentation, especially anonnet/src/crypt.c and anonnet/src/link.c.

Status:

  • Only anonymous key-exchange (anonymous, ephemeral Diffie-Hellman) is supported, at least until some kind of half-way decent node discovery mechanism can be implemented.
  • Uses Arcfour stream cipher for link-to-link encryption, Rijndael/AES block cipher for caller-to-node encryption, and Tiger-192 as the hash primitive for the key derivation function (aka hashed-based psuedo-random function) and HMAC (packet authentication).
  • AnonNet builds atop the PipeNet link & route design to combine multiple anonymous routes-- creating a "circuit"-- to increase throughput, and allow for some amount of spontaneous route tear-down while simultaneously keeping a reliable degree of "circuit" persistence. A pure PipeNet is extremely susceptible to DoS (denial-of-service) attacks, since it requires that any perturbation in the flow of a route force an immediate closure of all links at the first identifying node, initiating a devastating cascade throughout the whole network. Combining routes into a virtual circuit, along with judicious use of the tear-down rule, allows for some routes to fail without completely destroying the stream between the end nodes.
  • Due to a recent re-design, a full circuit cannot be constructed yet.
  • Cannot actually be used to transport any application network streams, but its close. Feel free to offer your assistance!

Download Snapshots:
anonnet-0.0.1-20021020.tgz (123KB) (before new layout)
anonnet-0.0.1-20011210.tgz (173KB)
anonnet-0.0.1-20011112.tgz (281KB)
anonnet-0.0.1-20010729.tgz (361KB)
anonnet-0.0.1-20010728.tgz (359KB)

Checkout CVS Source :
cvs -z9 -d :pserver:anoncvs@25thandClement.com:/var/cvs checkout anonnet
(or view the source interactively). 

Example compilation:

# Build AnonNet
#
# If you have source from CVS, you need automake and autoconf
# installed on your system, and to use them as such:
aclocal
autoheader
automake -a
autoconf

# Configure and build
#
# NOTE: --enable-debug keeps in-line debugging messages (aka eye candy)
#       see configure --help for more options
./configure --enable-debug
make

# Watch the tunnels' creation. See ./anonnet --help for more options
# Watching the tunnels setup via loopback is all you can see now, except the code ;)
cd src
./anonnet -c ./examplerc --debug --verbose

For more info write to William Ahern <william@25thandClement.com> or subscribe to the mailing-list:
send e-mail to anonnet-request@25thandClement.com with "subscribe" in the subject or body.

If you find this work useful, show your gratitude by giving back to the community.

Valid HTML 4.01!