Egregore / Blog: Recent posts

I'm pretty sure that when this software gets to a usable state[1] it will be damn hard[2] for spies to observe. You're more likely to be impersonated than cracked. Standard disclaimers about quantum WOPR's apply.

1. Usable also requires a fair number of users running routers to create anonymity.
2. Both the 2048 bit RSA and 256 bit AES keys each would take longer than the age of the universe to crack, assuming I didn't f*** up the code.... read more

I've had to drop things for a while, but I'm trying to get back to work on this. I was in the code for a couple hours tonight and things seems to be coming back in my brain so that seems nice.

Why am I getting these decryption errors, but not every time?
Why does the build circuit function occasionally fail?
Why is the destination router on the circuit not process the DHT query message?

I'm not sure which of these problems need to be solved first, or if there is another problem causing them that I haven't seen yet.

Code to set the default profile, and to remember the profile password is now working.

Since the last blog post, the SQLite library is working well. It has allowed the creation of an SQLite based data store for the DHT system. This has allows the DHT Nodes to limit the amount of data they store from a given peer, making it pretty much impossible for malicious peers to flood attack. In theory if an attacker controls a large enough number of IP addresses, (e.g. a huge sub-net or a huge bot net) they could send a large number of records out in an attempt to fill the database of a target node. ... read more

Between personal issues and trying to figure out what do to about eclipse attacks, it looks like there isn't much going on, but I assure you this is not true.

Basically here is the problem, A misbehaving node in the DHT system could perform what is known as an eclipse attack. Basically a bad node publishes lots of records to an ID they would like to hide (or eclipse). Depending on node storage behavior, this could cause valid data to be crowded out, or just consume lots of resources on the target node making it unavailable. So there must be a mechanic that limits the data a remote node can publish. ... read more

In case you missed it, in yesterday's large number of commits, there was one that states that circuit creation now works. This means under ideal conditions (e.g. my test setup) a router can now create a mixnet chain with other routers. This is the first step in anonymizing the system. This makes it such that a user's IP address is not revealed to other users. While it might still be possible to setup some rogue routers that capture and analyze traffic to do some statistical attack make guesses about who is talking to who, this is still a pretty good first step.... read more

So the CryptMessage is no longer a descendant of the base Message class used by other messages. The reasoning here, it that CryptMessage is now the only type of message that should be sent over the wire. Therefore the CryptMessage is basically a routing instruction (Circuit Key) and obviously an encryption wrapper. Therefore the only thing a crypt message reveals is what circuit a message goes on which is needed for mixnet routing. Everything else is hidden from intermediary routers. The ends or a circuit can determine how to decipher the message, and process the contents accordingly.... read more

I've gotten circuits to work over a single hop. Its forced me to think a lot about the messaging structure between routers. Its making for good brain teasers.

With a recent commit there was a comment "Changed the router location code to use Kademlia Node ID's as search keys to elminate the dependance on a single key id for routers." And I'd like to explain what that is.

First thing to understand is that Kademlia can be vulnerable to an Eclipse Attack, where an attacker is able to block access to all queries for a single key in the DHT. What I had originally done was to publish router contact details (IP address and port) under a single key. If an attacker went after this key, the Egregore client would not be able to find any routers to connect to effectively shutting down the entire network. This was clearly not acceptable. ... read more

Turns out that the Daylight DHT library uses a BinaryFormatter. This is fine when going from .Net to .Net, or Mono to Mono, but the data-grams generated are slightly different. Which means that somethings like a simple message (e.g. a PING or PONG) work just fine, but anything more complicated doesn't work because the deserialization on the receiving end fails.

Luckly there is a solution for this. The NetworkComm library I intend to use for the Messaging protocol uses something called protobuf-net{http://code.google.com/p/protobuf-net/} which is apparently some serialization scheme they came up with at Google. ... read more

In case anyone else ever runs into it, I somehow got my Mono install to run the Winforms code, but the GUI never displayed. 'sudo apt-get install mono-complete' seemed to have fixed it.

After much struggling with the beast. I got MonoDevelop 2.8.5 installed and running in an Ubuntu virtual machine. I also got Tortoise Hg to work, so that makes me happy. The code even compiles in MonoDevelop.

So a few problems to look forward to. The NetworkComms.Net library makes use of a Windows API call to GetBestInterface in iphlpapi.dll. In Linux this fails silently, so the LocalIP property is not automatically set. This is bad because it is a behavior I was counting on. So it looks like I get to look forward to mangling that code to not do that. Now I get to code up something like this:... read more

I've migrated over to .Net 4.0 and have started testing with the Network library mentioned in the last post. Things seem OK. I'd like confirmation that I didn't break Mono. I should setup my own test environment.

I'm Looking around at a way to make router to router communications easy. Right now I'm tossing around using NetworkComms.net, but it is .Net 4.0, and so far this project has been .Net 3.5. Back-porting NetworkComms.Net doesn't look like a task I can handle at this time. So switching to 4.0 maybe in the near future.

Mono should be compatible (and NetworkComms.Net advertises this.) So as a Windows guy I'm looking at switching the project to Visual Studio 2010. It seems there is something wrong with the code that causes an inelegant shutdown, and windows moans that the program didn't terminate as expected. Visual Studio Express 2010 isn't getting me any good info which means I might have to look at getting a different version of Visual Studio.... grr.