I2P

From Organic Design wiki
Revision as of 18:10, 20 June 2012 by Nad (talk | contribs) (→‎See also)

I2P is an anonymizing network, offering a simple layer that identity-sensitive applications can use to securely communicate. All data is wrapped with several layers of encryption, and the network is both distributed and dynamic, with no trusted parties.

Many applications are available that interface with I2P, including mail, peer-peer, IRC chat, and others.

The I2P project was formed in 2003 to support the efforts of those trying to build a more free society by offering them an uncensorable, anonymous, and secure communication system. I2P is a development effort producing a low latency, fully distributed, autonomous, scalable, anonymous, resilient, and secure network. The goal is to operate successfully in hostile environments - even when an organization with substantial financial or political resources attacks it. All aspects of the network are open source and available without cost, as this should both assure the people using it that the software does what it claims, as well as enable others to contribute and improve upon it to defeat aggressive attempts to stifle free speech.

Anonymity is not a boolean - we are not trying to make something "perfectly anonymous", but instead are working at making attacks more and more expensive to mount. I2P is a low latency mix network, and there are limits to the anonymity offered by such a system, but the applications on top of I2P, such as Syndie, I2P mail, and I2PSnark extend it to offer both additional functionality and protection.

I2P is still a work in progress. It should not be relied upon for "guaranteed" anonymity at this time, due to the relatively small size of the network and the lack of extensive academic review. It is not immune to attacks from those with unlimited resources, and may never be, due to the inherent limitations of low-latency mix networks.

I2P works by routing traffic through other peers, and all traffic is encrypted end-to-end. For more information about how I2P works, see the Introduction.

Naming & Addressing

Naming within I2P has been an oft-debated topic since the very beginning with advocates across the spectrum of possibilities. However, given I2P's inherent demand for secure communication and decentralized operation, the traditional DNS-style naming system is clearly out, as are "majority rules" voting systems.

I2P does not promote the use of DNS-like services though, as the damage done by hijacking a site can be tremendous - and insecure destinations have no value. DNSsec itself still falls back on registrars and certificate authorities, while with I2P, requests sent to a destination cannot be intercepted or the reply spoofed, as they are encrypted to the destination's public keys, and a destination itself is just a pair of public keys and a certificate. DNS-style systems on the other hand allow any of the name servers on the lookup path to mount simple denial of service and spoofing attacks. Adding on a certificate authenticating the responses as signed by some centralized certificate authority would address many of the hostile nameserver issues but would leave open replay attacks as well as hostile certificate authority attacks.

Voting style naming is dangerous as well, especially given the effectiveness of Sybil attacks in anonymous systems - the attacker can simply create an arbitrarily high number of peers and "vote" with each to take over a given name. Proof-of-work methods can be used to make identity non-free, but as the network grows the load required to contact everyone to conduct online voting is implausible, or if the full network is not queried, different sets of answers may be reachable.

As with the Internet however, I2P is keeping the design and operation of a naming system out of the (IP-like) communication layer. The bundled naming library includes a simple service provider interface which alternate naming systems can plug into, allowing end users to drive what sort of naming tradeoffs they prefer.

All destinations in I2P are 516-byte (or longer) keys. (To be more precise, it is a 256-byte public key plus a 128-byte signing key plus a null certificate, which in Base64 representation is 516 bytes. Certificates are not used now, if they are, the keys will be longer. One possible use of certificates is for proof of work.)

If an application (i2ptunnel or the HTTP proxy) wishes to access a destination by name, the router does a very simple local lookup to resolve that name. The client application (technically, the client side of I2CP in the I2P API) does a linear search through three local files, in order, to look up host names and convert them to a 516-byte destination key:

  • privatehosts.txt
  • userhosts.txt
  • hosts.txt

The lookup is case-insensitive. The first match is used, and conflicts are not detected. There is no enforcement of naming rules in lookups.

I2P also supports Base32 hostnames similar to Tor's .onion addresses. Base32 addresses are much shorter and easier to handle than the full 516-character Base64 Destinations or addresshelpers. Example: ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p. I2P uses 52 characters (256 bits) to represent the full SHA-256 hash. The form is {52 chars}.b32.i2p. Base32 is implemented in the naming service, which queries the router over I2CP to lookup the LeaseSet to get the full Destination. Base32 lookups will only be successful when the Destination is up and publishing a LeaseSet. Because resolution may require a network database lookup, it may take significantly longer than a local address book lookup.

Base32 addresses can be used in most places where hostnames or full destinations are used, however there are some exceptions where they may fail if the name does not immediately resolve. I2PTunnel will fail, for example, if the name does not resolve to a destination.

There is an application bundled with the install called addressbook which periodically retrieves other users' hosts.txt files and merges them with the local hosts.txt, after several checks. Naming conflicts are resolved on a first-come first-served basis. Another bundled application called SusiDNS is a web interface for configuring addressbook subscriptions and accessing the four files.

Entries can be imported with a direct URL to the local SusiDNS interface. The address in in the format of http://127.0.0.1:7657/susidns/addressbook.jsp?book=private&hostname=NAME&destination=DEST where NAME is the .i2p hostname and DEST is the 516 character network destination.

Installing on Debian/Ubuntu

I2p-start.jpg

There are packages available for Debian and Ubuntu in their site here. I decided to download the source and which also required me to install the java-6-openjdk and ant packages before running ant pkg in the unzipped source directory. This ran through the compilation process which took a couple of minutes, and then I downloaded and ran the graphical installer with java -jar i2pinstall_0.9.jar. After installation a browser window opens with a great deal of information about the running service with many statistics and configuration options.

To be able to visit .i2p "eepsites", the browser proxy needs to be configured to use port 4444 (4445 for HTTPS).

Firewalls

While I2P will work fine behind most firewalls, your speeds and network integration will generally improve if the I2P port is forwarded for both UDP and TCP. If you think you have opened up your firewall and I2P still thinks you are firewalled, remember that you may have multiple firewalls, for example both software packages and external hardware routers. If there is an error, the logs may also help diagnose the problem.

See also

Retrieved from "https://organicdesign.nz/wiki/index.php?title=I2P&oldid=109530"