Eternity - an alternative approach

[Kay Ping]

-----BEGIN PGP SIGNED MESSAGE-----

In one of the messages on the eternity thread someone suggested using
radio signals. This is an interesting approach which certainly deserves
further attention but digital radio requires special hardware which I prefer 
to avoid. However, some of the characteristics of radio signals can be 
emulated on the internet.

Radio links are perfect for hiding the location of receivers. The
equivalent for this is of course services like usenet and IRC. Both are
already used for providing anonymity.

Radio is also quite good at hiding the location of the transmitter - you
tune your radio and the signals are just there, coming down your antenna.
It takes special equipment to locate where they originated.

It occured to me that the equivalent on the net would be to receive
packets with invalid source addresses. They are just there, coming dowm
the phone line to your modem. It takes significant resources and snooping
on a massive scale to locate where they are coming from.. All this is
assuming you can find some way to send a request with your address to the
server.

For eternity this means that the location of servers where documents are
stored can be kept secret if they transmit the documents using packets
with invalid source addresses. Receivers of eternity documents will not
be able to tell where they are coming from.

Since there is no bidirectional link between transmitter and receiver the
protocol must be implemented over UDP. To protect against packet loss the
data may be encoded with redundancy. The correction code can be similar
to that used on RAID disk arrays - adding redundant blocks consisting of
XOR of other blocks. Missing blocks can be reconstructed by XORing
together other blocks received.

To provide even better anonymity the transmitter may send the messages
through one or more onion routers which decrypt one layer of encryption.
These routers do not store information, do not know what information
passes through them and do not know where it's coming from. Any packets
they forward are sent without a valid source address. This should make
them less vulnerable to attacks of all kinds. Can anyone speculate about
their liability under US law?

Putting caches on the routers will help both performance and security.
Will it affect their liability in any way?

If encryption is implemented properly all packets will look identical:
blocks of random data of the same size and no source address. This will
make traffic analysis difficult. The distance to the transmitter can be
hidden by initializing the packet's time-to-live field to a value with
random variations.

That was the easy part. The hard part is to get the requests to the
document servers without knowing their addresses. This can be done
through the equivalent of remailer reply blocks or some kind of broadcast
medium.

The reply blocks would be implemented by the onion routers. Each hop
could generate several copies, both for redundancy and as decoys.
Packets used in reply blocks can look identical to packets with document
data, including the use of invalid source addresses.

In the broadcast version clients and servers subscribe to channels with
many participants to hide their identity in the crowd. The system could
use an existing service like IRC or a dedicated network, possibly based
on modified IRC server code.

Sympathizers with bandwidth to spare can subscribe too to provide better
cover for the actual document servers. Servers could listen using trusted
proxies or chains of semi-trusted proxies. The division into channels
allows growth of the system if the total bandwidth of requests becomes
too high.

Using the public IRC networks has the advantages of being less suspicious
and not requiring the deployment of new infrastructure. Requests could
even be hidden steganographically in IRC traffic. Unfortunately, IRC
server operators are touchy about abuse of their systems.

Requests should be small. This allows replicating them to a large number
of receivers without taking too much bandwidth. They can also be made to
be of fixed size and contain no controversial information. Requests
contain the document index as a compact one-way hash, the requester's IP
address and the server's ID code. It may also contain hashcash or ecash
payment. Requests should be encrypted to the server's public key. To keep
them small, elliptic curve encryption may be used.

A server may send random cover packets to hide the correlation between
a request and its response. It may also add random delay before
responding to the request. Delay will also help limit the bandwidth.
Users of eternity need to be more patient that the average web surfer and
the protocol should use generous timeouts. Since UDP has no flow control
the server should always assume the client is using a modem connection
and limit its transmission speed accordingly. Security has a price.

The client software may be implemented as a local web proxy (in Java?)
which identifies requests to eternityspace and converts them to this
protocol. Public gateways may be set up to allow anyone to read eternity
URLs. These public may also be used to protect the anonymity of the
reader like the Anonymizer.

Document servers and routers must be located on networks where there is
no spoofed packet filtering. Since the common use of spoofed packets is
in denial-of-service attacks more and more filters are being installed.
It may become harder in the future to find places to put the servers and
routers. I believe it should always be possible since it is not practical
to implement filtering in places where there is a lot of traffic from
different sources. In cases where the document server is located on a
filtered network it may have to trust the routers to hide its location.

This system is far from perfect: it has too many components and the weakest link is the transmission of requests to servers. I still believe it has some interesting sides which deserve further discussion. Your ideas are welcome.

- -----------------
Kay Ping 
nop 'til you drop

finger kping at nym.alias.net for key
DF 6D 91 18 A6 59 41 96 - 89 01 69 B7 9D0 4 AE 53

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: cp850

iQEPAwUBNL26txHPAso8Qp7tAQGLEAfPeRgIL3OqiG67CLBO9TCe/oV5lmw66Pz1
Wl17ajHeSCX6qjACSZ3La73drUjIftL0G/18PkLd48VGmsF6izCnXB4fh8MAB6Ve
QWjhRTvRSkKkwXK4t2tx6CUCdxOaJ9Phd6J02Z+MdjEGJ3jAdUdaHWo5zM5i6Ris
wkgATEhGMpw8tjlnvR4erwu51iSrt62huPWJXl1pjyPfQbl0iyQtcGdQ1spIWLJC
oaOI7QchHK3LjSuzN54MVCjRdz8fiI6JHAUnlqqsW29LBOZQkSnQedORCuIALwqe
qOhSxMKbciLdVde3BBtpILpz5y91ulAecxOOwcnc7m5Pjw==
=iLP5
-----END PGP SIGNATURE-----