D 2014-07-03T14:31:03.271
L onion-routing
P 0844f5278d313d59506e14e6d301c038d3a85a60
U bernd
W 4741
<h1>Onion Routing</h1>
<p>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.</p>
<p>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.</p>
<h2>TOR design problems</h2>
<p>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.</p>
<p>Therefore, anonymous relays only work well when many participants distribute
the load, and can't easily be scared to turn it off.</p>
<h2>net2o onion routing</h2>
<p><i>This is not yet implemented</i></p>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<p>Relay generation is just one single command:</p>
<p><font face="Courier New">create-relay ( $key $address -- prefix )</font></p>
<p><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></p>
<p><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></p>
<h2><font face="Arial">Downsides of Onion Routing</font></h2>
<p><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></p>
Z 6fddbfbaee147597e838bc890a3b4df3