Anonymity is somewhat orthogonal to encryption: The routing information in your message reveals who's talking to whom. The TOR project suggests that anonymity can be achieved by using several hops, and decrypting the message blocks on each hop, routing them forward to another hop.

The requirements for onion routing cryptography are different from the rest of net2o cryptography. The intermediate hops don't need to authenticate the blocks; in fact, it is better when they don't even know who's sending them.

TOR design problems

TOR has some design problems, one is the mostly centralized dictionary. Everybody asking the directory server is exposed as obvious TOR user. This can be easily mitigated by using a DHT. Another problem is not related to TOR itself, but to the current internet: The traffic from TOR exit nodes and beyond is often unencrypted; as TOR exit nodes are easy to spot (they are listed in the directory server), they are very likely to get special treatment, and all traffic is monitored. Scaring TOR exit node operators into shutting down their services reduces bandwidth, and makes TOR difficult to use.

Therefore, anonymous relays only work well when many participants distribute the load, and can't easily be scared to turn it off.

net2o onion routing

This is not yet implemented

As onion routing uses cryptography on already encrypted and authenticated packets, and should not increase the size of the packets, I will use a block cipher, with an AES-XEX variant or Threefish when the cost of AES is too high. The destination memory address and the second flag byte will also be encrypted, using ECB (taking the first part of the message to fill the 16 bytes), the decrypted memory address is the sector index for AES-XEX or the tweak for Threefish. This encryption is not tamper-proof, but tampered packets will be filtered out at the legitimate destination. The requirement here is that it is harder to correlate input and output of a relay through decryption than through other means.

The most interesting problem however here is how to not expose the routing field, because it contains the path through the onion routing network, and also selects the proper key. So the routing field needs to be encrypted and it is used to identify the connection while encrypted. The routing field is still used to forward packets, though the routing within the onion network is set up before, so it's mostly a switched circuit network. Handovers should be negotiated separately.

The good news is that it doesn't need to be ultra reliable. If we find that two keys possibly match, we can just decrypt and forward the packet with two keys to two different destinations. It will be thrown away if it doesn't match further, at least at the endpoints. I'm not convinced that the normal 16 byte path is sufficient for onion routing, especially, as the normal path is needed to get from one onion router hop to the next, too. So onion routing needs an additional, longer, constant-size path within the onion network. Like the rest of the message, the onion path is encrypted/decrypted on each hop, and the end node just flips the path so that the inserted pathlets can be used as return path.

Each element of the path is per-hop encrypted/decrypted in ECB mode, so encryption and decryption are interchangeable operations (4 times decrypted with key1 to key4 and then encrypted with key4 to key1 gives us the plaintext again). To find the correct key, the router tries all available keys from a single source, and stops if the decrypted destination looks legit; since there is no requirement for ultra-reliability, a short IV and a simple checksum is sufficient (e.g. 32 bit each). One bit in the address is used to determine whether that's the endpoint of the onion routing or not. If you are endpoint, you keep the return path and create a normal net2o packet; the inserted return path allows to identify the onion routing path.

The relay uses the same key for both directions, one direction uses encryption, the other decryption. The originator needs to know all keys, and encrypt with all of them on sending, and decrypt with all of them on receiving - so the originator actually computes those keys. Therefore, a fast, hardware-accelerated algorithm is important here; security concerns about AES weaknesses and mode problems are secondary. This is only making it more difficult to compute a correlation, breaking the encryption therefore should only be harder than any other mean to correlate packets (e.g. using timing attacks). The content encryption is below that layer; using an entirely different algorithm provides additional security: Attackers of relayed traffic need to break two encryption schemes. You can setup a relay to itself on your destination to add an AES encryption on top of Keccak encryption, the destination then only receives packets which look like relayed packets.

The relay may slow down packet rates to make correlation harder, but is not allowed to speed up bursts, because that would break net2o's flow control (partial speed up inside a burst is allowed, though). Relays shall do fair queuing to help the flow control.

Relay generation is just one single command:

create-relay ( $key algo -- )

Relays automatically are shut down after 1 minute of inactivity; relays are created with only one-time keys, because you don't want the relay to know who you are, but you want to know that the relay is the one you asked, so you want its pubkey, and use another one-time key to generate the shared secret. There's no full connection setup with a relay, setting up a relay should take three messages only.

You can create relay trees (with the root in the target you talk to), and switch between leaves randomly, as net2o provides perfect handover support. Different paths shall have different sets of keys, you will know which path has been used.

Downsides of Onion Routing

Onion routing increases latency and traffic. If you want to minimize on that, use relays close to you (in terms of network distance). As big internet exchanges are much more likely to be monitored, local relays also provide less means to collect correlations.