waste - security model and implementation

WASTE Security Model and Implementation

WASTE builds a distributed network of hosts, and secures each link in the network. In securing each link, WASTE also authenticates each link using public keys.

WASTE also provides a mechanism for hosts on this network to exchange keys automatically with each other once a host is trusted on the network.

How WASTE Secures Links
WASTE secures the links of the WASTE network by using RSA to exchange session keys and authenticate the other end of the connection. Once the hosts have authenticated each other and both have the correct session keys, the connection is encrypted using Blowfish in PCBC mode (using different IVs for each direction of the connection). The oversimplified process for bringing a link up is (see comments in the code and the code itself for a more in depth view):

Both sides exchange public key hashes, and verify that they know that hash
Both sides exchange session keys and challenge-response tokens encrypted with each others public keys.
Both sides decrypt and verify the challenge-response tokens, and begin encrypted communication (a stream of messages, each message is verified using an MD5).

There's a lot more to it than that, but that's the basic idea. The reality of it is that there is also a "Network ID/Name" feature that allows you to easily keep networks from colliding, as well as efforts to obfuscate the whole process (to make WASTE connections difficult to detect). Another unique feature is the way session keys are exchanged and combined so that in order to decrypt past (recorded) traffic, both private keys of a connection need to be recovered.

Note: It might be worth implementing WASTE using a subset of SSL, to avoid any concern of flaws in this protocol. Feedback is gladly accepted on any potential weaknesses of the negotiation. We have spent a decent amount of time analyzing this, and although we have found a few things that are not ideal (i.e. if you know public keys from a network, you can sniff some traffic and do an offline dictionary attack on the network name/ID), but overall it seems decent. The current implementation probably needs work, too.

Why WASTE requires a trusted group
Since the security in WASTE relies on encrypted links, and messages are not encrypted point to point, a node on the trusted network could easily sniff or spoof messages. So yes, your friends can spy on you. But you were not really worried about them, were you?

How WASTE Prevents Information Leakage
WASTE makes an effort to prevent information leakage. WASTE sends all traffic through the same encrypted link(s), and does not (by default) bring up or drop connections in response to any user actions. WASTE messages are sent completely inside an encrypted channel, so a snooping party would have a VERY difficult time determining what kind of traffic is being sent across a link, or where the traffic originated from, or where the traffic was headed to. And because there may be redundant paths in the network, and traffic is load balanced across those paths, it further complicates things.

In addition, WASTE has an optional saturation feature, in which connections can be saturated to a particular rate (with random data, if necessary), so that a snooping party cannot see how much real data is being moved.

How WASTE Exchanges Keys Between Trusted Hosts
In order for two WASTE hosts to connect to eachother, they need to know eachothers public keys. This can happen two ways. The first way, which is how you would initially connect to a WASTE network, is by manually exchanging public keys. This is clunky, and generally a PITA.

Once a WASTE host is on a WASTE network, however, it can (and is by default) be configured to automatically exchange public keys with other hosts on the network. This happens through the secure links of the network.

The main drawback to this is that it is very difficult to remove a key from the network. Each node on the network that that person could potentially connect to has to remove the key. This may be addressed in a future version.