I2P Anonymity

Dead Fish Service

(Another name of such a DFS can be RFS: Rotten Fish Service)

If it smells like a dead fish, it probably can be detected easily.

The idea behind this is threefold:

• Get rid of static keys for eepsites.
  
• Get rid of hosts.txt
  
• Anonymize the source of information by caching
  

This text is terribly incomplete.

Why eepsites smell like dead fish

Think of following:

You run an eepsite. This eepsite is entered into hosts.txt. People access this eepsite. But nobody knows you, so you think you are safe.

Now you do something, which is not a bad thing, but some people consider it harmful. They get a court order and start to confiscate I2P nodes until they hope to get you. You now have two options:

1. Take down your eepsite or
   
2. face the consequences somebody will reach you.
   

Problem #1

You cannot re-open your eepsite once you think they got near you. As they know who was clean and therefor start to look for others. Checking if an eepsite is running on your node is easy:

• Just turn off the IP interface of a computer for a certain time. For you it looks like it's an ervice outage, but for scanners they can detect that taking down your interface takes down the eepsite as well.
• You cannot tell if the router is running the eepsite or providing it. But that's easy to discriminate, too: Just do it more often. If the eepsite in question goes down all times when your interface is down, you are caught!

That's inacceptable

Solution #1

The solution to this dilemma is that taking down an eepsite must not take it down.

• One solution to this is to do it as freenet. However this is bad, as freenet does not allow to permanently offer your content.
• A second solution is like BT with a seeder. As long as the swarm has data, the data is there. With a permaseed, you can always be sure to get the data. If it is porperly constructed, you cannot tell where the data comes from. See below.

I think, this is the way to go.

Problem #2

If you can get access to a node, the private key is stored on disk. It cannot be encrypted, as I2P must be able to read it to provide the tunnel endpoint.

That is bad, as the Tunnel endpoint exposes you and shows, that you are very likely the source of data sent out from this tunnel previously (well, you can have stolen the key, but ..). Even worse is, that everybody who has access to your hard drive can take over your eepsite this way.

Prompting for a password (like apache-SSL) is not the right solution again, as it might be that somebody installed a key sniffer on your I2P router without you noticing this fact.

Solution #2

There must not be a fixed key to eepsites.

The idea to archive this, is to sign the data instead of using tunnel endpoints. Everything signed by the signature then is considered to be from this eepsite. So you do no more define "Tunnel endpoint" but "Data source". The data, however, can come from any system out there.

Put it together

hosts.txt shall not be used for eepsites directly. tino.i2p is my eepsite. But this is bad. It shall be my directory, where I can announce several things, like eepsites. This announcment area shall not be only for me. It shall keep only 1% personal information (or less) and 99% network cache.

So if you want to access the eepsite tino.i2p, then you query the directory at tino.i2p for the eepsite. This then points to a tunnel, which you can access as previously.

The interesting thing is the additional indirection. This way you can enter and change the key of the eepsite. If you like, you can even change this key each time the I2P node is rebooted, or more often.

This does not help, you think. No, this helps a lot. As you only provide the directory, you can add additional eepsites in it. Like fproxy.tino.i2p (queries directory tino.i2p!). You do not need to provide this yourself. Or others can ask, if you would be so kind, to provide this entry.

However this is not flexible enough. Handing out the tunnel directly can be error prone if somebody takes over your directory. Therefor the directory entries must be signed. Signed by a key, which need not be kept on harddrive. And allowing only for one layer of indirection is not enough, you need several indirection layers.

Now the interesting part starts:

You do no more need hosts.txt, only just some directories to ask, which in turn allow you to add (announce) your information as well. So slowly the information source are propagated through the network but not each node needs to know everything (it can point you elsewhere).

The information will not be endless. It only stores pointers to directories which in turn might answer the question. Only alive entries are kept. And not all entries are kept everywhere. So it's just like the DNS resolver, which caches some information locally, but does not cache everything.

Another interesting thing would be to provide mirrors to some eepsites. If you think, an eepsite is interesting, you can tell your directory to provide mirror to it. Your directory then will accept a certain amount of data from this eepsite (etc.), up to the sharing levels you entered:

• The mirror rate.
  
• And the minimum mirror count.
  

For example, you can tell your directory "mirror this site completely here" or "mirror only the stuff, for which mirror count is below 5, thus less than 5 other (known) mirrors have the data, too".

The data then is signed by a key. The key can be in-memory of the I2P router, so that it vanishes, as soon as you restart the router. This in-memory key is signed by a signer key. This one can be on harddrive. However this still is not the source key, as the source key can sign this key. Or even deeper. So if you want to know if some file is from source X you follow the signer chain until source X is found. If recoursion is too deep (10), it is stopped.

As the data is signed it is irrelevant if the data comes from the right tunnel. The tunnels are then independent of the data transmitted. So any dictionary can provide a mirror of (static) data.

Dynamic data is something completely different. It must be created on the eepsite.

The interesting thing here is, again, that a directory can act as a forwarder to this data. This is, it just sends you the data, instead of the real eepsite. It decides to do so on free will. As more dictionaries offer this service, the network becomes more anonymous, so it is in your interest to provide such a service, as it also allows you to neglect that you are the source of the data.

Difficult

It is more difficult as it seems to implement. I only showed some basic concept. It's extremely complicated to do this reliably. Therefor I am unable to make it myself.

But I can note it here.

'nuff said. Running out of time now. Leaving.

-Tino