Onion Routing

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.  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. 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.

Relays use the remaining address path as index into an internal table to find the target.  The return path is also indexed internally.  The relay sets a key for both parts, 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 should do fair queuing to help the flow control.

Relay generation is just one single command:

create-relay ( $key $address -- prefix )

you get a path prefix as literal (64 bit maximum). 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 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 can 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.