D 2014-07-03T13:07:42.916
L onion-routing
U bernd
W 4768
<h1>Onion Routing</h1>
<div>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.</div>
<div>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.</div>
<h2>TOR design problems</h2>
<div>TOR has some design problems, one is the mostly centralized dictionary.
Everybody asking the dictionary 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.</div>
<div>Therefore, anonymous relays only work well when many participants
distribute the load, and can't easily be scared to turn it off.</div>
<h2>net2o onion routing</h2>
<div><i>This is not yet implemented</i></div>
<div>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 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.</div>
<div>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.</div>
<div>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.</div>
<div>Relay generation is just one single command:</div>
<div><font face="Courier New">create-relay ( $key $address -- prefix )</font></div>
<div><font face="Arial">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.</font></div>
<div><font face="Arial">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.</font></div>
<h2><font face="Arial">Downsides of Onion Routing</font></h2>
<div><font face="Arial">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.</font></div>
Z e8be9b40e6c25d206c6affd4f749e53a