Difference between revisions of "I2P"

From Organic Design wiki
(Installing on Debian/Ubuntu: debs)
(Connecting to #agora: restart daemon)
Line 153: Line 153:
 
[[File:Agora-irc-address.jpg|614px|center]]
 
[[File:Agora-irc-address.jpg|614px|center]]
  
Next you'll then need to go to the local configuration page for ''tunnels'' at http://127.0.0.1:7657/i2ptunnel and then either edit the existing IRC tunnel if there is one, or create a new one. Put it on the local '''127.0.0.1''' IP address with port '''6668''' and use the '''agora.anarplex.i2p''' which now resolves to the correct I2P encrypted address. Save the new settings and start the tunnel.
+
Next you'll then need to go to the local configuration page for ''tunnels'' at http://127.0.0.1:7657/i2ptunnel and then either edit the existing IRC tunnel if there is one, or create a new one. Put it on the local '''127.0.0.1''' IP address with port '''6668''' and use the '''agora.anarplex.i2p''' which now resolves to the correct I2P encrypted address. Save the new settings and start the tunnel. Sometimes I've had to restart the i2p daemon after adding the private address book entry before the tunnel could use it.
  
 
[[File:Agora-irc.jpg|600px|center]]
 
[[File:Agora-irc.jpg|600px|center]]

Revision as of 16:41, 12 April 2013

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 install using the .deb packages, add the source and apt-get install i2p, then use dpkg-reconfigure i2p to have it start up automatically and to set the amount of memory it uses. You can then do more specific configuration from the local configuration page.

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.

The Network Database

I2P has a built-in Network Database which is a specialized distributed database (using a modification of the Kademlia algorithm), containing just two types of data - router contact information (RouterInfos) and destination contact information (LeaseSets). Each piece of data is signed by the appropriate party and verified by anyone who uses or stores it. In addition, the data has liveliness information within it, allowing irrelevant entries to be dropped, newer entries to replace older ones, and protection against certain classes of attack. The netDb is distributed with a simple technique called "floodfill", where a subset of all routers, called "floodfill routers", maintains the distributed database.

I2P Mail via Thunderbird

Setting up email in i2p has a few pitfalls, mostly due to erroneous documentation in the i2p network AND because the the confusing setup of thunderbird using multiple accounts and identities. The general steps are according to the Mailsystem Documentation in the i2p network.

Make sure your pop3 and smtp tunnels are working

  • visit the tunnel manager on your localhost and look for:
Name: smtp.postman.i2p  Port: 7659  Type: Standard client  Interface: 127.0.0.1  Destination: smtp.postman.i2p
Name: pop3.postman.i2p  Port: 7660  Type: Standard client  Interface: 127.0.0.1  Destination: pop.postman.i2p
  • Both should have green stars (but seem to work when the star is yellow in some cases)
  • Make sure no other tunnels have the same port numbers, which would cause a conflict
  • Perform the telenet tests for both [smtp http://hq.postman.i2p/?page_id=10] and pop3 tunnels

The instructions for the telenet to pop.postman.i2p are erroneous! This is the correct procedure:

# telnet localhost 7660
Trying 127.0.0.1…
Connected to localhost.
Escape character is ‘^]’.
+OK ready
user pseudonym
+OK Password required for pseudonym
pass thepassword
+OK pseudonym has 1 visible message (0 hidden) in 456 octets.
quit
+OK OK - Bye
Connection closed by foreign host.

Note that in the above test, if you use 127.0.0.1 instead of localhost, it should still work, but the OS may lie to you and say that the pop3 server's name is something like register.adobe.com - this is the result of entries in your hosts file put there for the purpose of 'blocking' certain phone home sites that some commercial applications try to send to, so they are looped back to 127.0.0.1 - it shouldn't matter because whatever name resolves, it is still forwarding to 127.0.0.1 on the port to your i2p proxy. You will notice that you are still, in fact, interacting with a live pop3 server. No worries!

Setting up Thunderbird to transport mail via i2p

Outgoing Server (SMTP)

It's very important that you do this before creating a new mail account in Thunderbird, because if you don't, the new identity will take the existing default outgoing server, like smpt.googlemail.com - which would be very bad because not only will your first "test" mail go through google, but it will have the default identity's sender name stamped on the message - probably your actual name. This rather defeats the purpose of using i2p. If you think this data is not logged and 'fused' - think again! This is probably the main reason i2p strongly recommends that you start with a virgin, dedicated mail client. Ultra paranoid users may even want to sandbox a separate instance in a Virtual Machine running in VMWare.

settings:

Description: smtp.postman.i2p
Server Name: 127.0.0.1
Port: 7659
----
Connection security: none
Authentication method: password, transmitted insecurely
User Name: pseudonym 

(the one you registered with postman.i2p)

Add Mail Account

Account Name: pseudonym@mail.i2p 

(the one you registered with postman.i2p) i recommend using this 'internal' address format to always remind yourself that you are dealing with a precious and sensitive identity.

Your Name: plausible pseudonym"

This is going to show in the 'from' part of the message header.

Email Address: pseudonym@mail.i2p

(the one you registered with postman.i2p) This is the "internal" i2p format, not the mangled form used for outside of the i2p network (i.e. pseudonym@i2pmail.org) An ordinary smtp server in the wild internet will reject it as malformed. In fact the first time you create the account in Thunderbird, the wizard will warn you to check it.

Reply-to address: (blank)

IMPORTANT! at the bottom look at Outgoing Server (SMTP) - be sure you select smtp.postman.i2p - 127.0.0.1 - otherwise the default will be used! (such as gmail's smtp) Bad, Bad, Bad!

Finally: click 'Manage Identities' to get into the multiple identities support for this account. Be sure your @mail.i2p address is the only one in the list. If your regular email address is in the list - delete it - otherwise you could accidentally (by default) try to send from that address through i2p, which will be rejected, or worse, compromise your anonymity.

Edit the @i2p identity. Look over Settings and be sure the name is what you want, the email address is correct, and most of all, the outgoing (SMTP) is smtp.postman.i2p - 127.0.0.1

Then click on Copies and Folders, if you check place a copy in: be sure this is set to "Sent" folder on: pseudonym@i2p - otherwise it could end up in your gmail "sent" folder and leak into the wild internet. The same goes for "archives" "drafts" and "templates" - by default they could be pointed to your default mail folder (gmail, etc)

OK, and Close

Receiving mail

Note that the screenshot at the bottom of the Using POP3 Services page is also erroneous. It shows IMAP Mail Server as the server type. It should say POP Mail Server (this is determined when you create the mail account in Thunderbird).

Of course pseudonym should be your actual username that you registered at Creating a Mailbox

In the accordion list, click

Server Settings for the mailbox.

Server Name: 127.0.0.1 
Port: 7660 

(the POP3 mailbox from which the client retrieves mail)

User Name: pseudonym

(must match that which is registered with i2p)

Connection security: None
Authentication method: Password, transmitted insecurely

Server settings

Yes: check for new messages at startup
Yes: check for new messages every 

(a fairly long period, such as an hour, i2p performance is degraded with multiple unnecessary pings every few minutes) ...

No: leave messages on server 

(i2p is not in the business of storing large amounts of email. Be courteous of the people hosting the mail services!)

Copies and Folders check settings for Copy, Archive, and Draft - you don't want these synching with your gmail, yahoo, or msn accounts ... Return receipts Better not leave global return receipts preferences. So: Customise > Never send a return receipt.

Sending mail

Now it should be possible to perform a test from @mail.i2p to @mail.i2p - NEVER send test mails to/from your regular email account. This will certainly link the two identities, which belies the whole purpose of i2p mail.

You can use a throw-away account at a temporary email service like mailinator.com to test outbound mail to the regular wild internet into the i2p mail gateway. Don't use an address you have used before, and never use that address again. If this works, you should be able to start using the "external" (called 'mangled') address to give to those poor lost souls on the regular spy internet. It is of the form: pseudonym@i2pmail.org

Any external recipient you i2pmail to will see that address and that is the one to which they would reply. But once it enters the i2pmail gateway, it will be demangled to pseudonym@mail.i2p and delivered to your Thunderbird client. Voilá!

Connecting to #agora

The preferred way of connecting to the #agora channel is over I2P and with OTR installed for strong encryption on private chats. The procedure for connecting over I2P is rather complicated.

After you have successfully installed I2P, you'll first need to import the agora.anarplex.i2p address into the i2p router. One way to do this is to import an address book that already has the agora address in it, but in this case a link to the local address importing application with the hostname and 516 character destination is included in the MOTD of the channel (or try this link). I added http://inr.i2p/export/alive-hosts.txt to the subscriptions which you can edit at http://127.0.0.1:7657/susidns/subscriptions then save and reload, but if you imported from the direct link you should see the entry in your private address book which you can view from this link and it should show the entry like this:

Agora-irc-address.jpg

Next you'll then need to go to the local configuration page for tunnels at http://127.0.0.1:7657/i2ptunnel and then either edit the existing IRC tunnel if there is one, or create a new one. Put it on the local 127.0.0.1 IP address with port 6668 and use the agora.anarplex.i2p which now resolves to the correct I2P encrypted address. Save the new settings and start the tunnel. Sometimes I've had to restart the i2p daemon after adding the private address book entry before the tunnel could use it.

Agora-irc.jpg

Once you're tunnel is showing as active (a green light next to it), you can then configure the account in your chat client which is simply a standard IRC client connecting to 127.0.0.1 on port 6668 as you specified in the tunnel configuration previously. Once the account is connected, you can then create a persistent channel connection to #agora as usual. If your tunnel is not working or there are other problems, check the logs for troubleshooting information.

Soon after connecting you'll be notified that you need to register your nick with the server, which is done with /msg nickserv register PASSWORD EMAIL. You'll be asked to enter this commend every time you connect, so I'd recommend you set up an automatic channel registration or a auto-replaced term so you can do it easily each time. NOTE: this is not obligatory.

Note: if it's not working, make sure you don't have two tunnels on the same port as in this screenshot. This can happen if you created a new tunnel on port 6668 without deleting the default one first. Alternatively you can just edit the default one to have the correct settings instead of creating a new one.

Note: If you are using Adium, a native Mac port of Pidgin, be aware that when creating a new account to connect to 127.0.0.1, the server account has an 'alias' field, which appears to be a short name for the server but ends up being used as your nick. When you edit personal data, you choose a nick and real name, but Adium ignores the personal nick and connects to the irc server using the "alias" as your nick. Therefore, put your nick as the server alias.

See also