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.
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 has 4 major goals:
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:
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.
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
If you find this work useful, show your gratitude by giving back to the community.