here's some content that might help someone who wants to put together an application developer's guide for I2P - I dont have time to polish this up before I leave, but thought it might be of use to someone. Feel free to tear this up, edit like mad, or just read it :)

Application development guide

Why write I2P specific code?

Using mihi's I2PTunnel application, you can hook up application instances and +have them talk to each other over standard TCP sockets. In plain client-server +scenarios, this is an effective technique for many simple protocols, but for +distributed systems where each peer may contact a number of other peers (instead +of just a single server), or for systems that expose TCP or IP information within +the communication protocols themselves, there are problems.

With I2PTunnel, you need to explicitly instantiate an I2PTunnel for each peer +you want to contact - if you are building a distributed instant messenger +application, that means you need to have each peer create an I2PTunnel 'client' +pointing at each peer it wants to contact, plus a single I2PTunnel 'server' to +receive other peer's connections. This process can of course be automated, but +there are nontrivial overheads involved in running more than just a few I2PTunnel +instances. In addition, with many protocols you will need to force everyone to +use the same set of ports for all peers - e.g. if you want to reliably run DCC +chat, everyone needs to agree that port 10001 is Alice, port 10002 is Bob, port +10003 is Charlie, and so on, since the protocol includes TCP/IP specific information +(host and port).

Applications that are designed to work with I2P can take advantage of its +built in data security and optional pseudonymous authentication. All data sent +over the network is transparently end to end encrypted (not even the router's +get the cleartext), and any application using the ministreaming or datagram +functionality has all of that data authenticated by the sending destination's +public key. As an aside, environments where anonymity instead of pseudonymity +is required are trivially accomodated by either using the I2CP directly, SAM RAW +sessions, or by simply creating a new sending destination whenever needed).

Another important thing to remember is that I2P is simply a communication +system - what data is sent and what is done with that data is outside of its scope. +Applications that are used on top of I2P should be carefully sanitized of any +insecure or identifying data or protocols (hostnames, port numbers, time zone, +character set, etc). This in and of itself is often a daunting task, as +analyzing the safety of a system that has had anonymity and security strapped on to +it is no small feat, giving significant incentive to learn from the experiences of +the traditional application base, but design the application and its communication +protocols with I2P's anonymity and security in mind.

There are also efficiency considerations to review when determining how to +interact on top of I2P. The ministreaming library and things built on top of it +operate with handshakes similar to TCP, while the core I2P protocols (I2NP and I2CP) +are strictly message based (like UDP or in some instances raw IP). The important +distinction is that with I2P, communication is operating over a long fat network - +each end to end message will have nontrivial latencies, but may contain payloads +of up to 32KB. An application that needs a simple request and response can get rid +of any state and drop the latency incurred by the startup and teardown handshakes +by using (best effort) datagrams without having to worry about MTU detection or +fragmentation of messages under 32KB. The ministreaming library itself uses a +functional but inefficient scheme for dealing with reliable and in order delivery +by requiring the equivilant of an ACK after each message which must traverse the +network end to end again (though there are plans for improving this with a more +efficient and robust algorithm). Given that as the current state, an application +that uses one of the I2P message oriented protocols can in some situations get +substantially better performance.

Important ideas

Destination ~= host+port

An application running on I2P sends messages from and receives messages to a +unique cryptographically secure end point - a "destination". In TCP or UDP +terms, a destination could (largely) be considered the equivilant of a hostname +plus port number pair, though there are a few differences.

Anonymity and confidentiality

A useful thing to remember is that I2P has transparent end to end encryption +and authentication for all data passed over the network - if Bob sends Alice's destination, +only Alice's destination can receive it, and if Bob is using the datagrams or streaming +library, Alice knows for certain that Bob's destination is the one who sent the data.

Of course, another useful thing to remember is that I2P transparently anonymizes the +data sent between Alice and Bob, but it does nothing to anonymize the content of what they +send. For instance, if Alice sends Bob a form with her full name, government IDs, and +credit card numbers, there is nothing I2P can do. As such, protocols and applications should +keep in mind what information they are trying to protect and what information they are willing +to expose.

I2P datagrams can be up to 32KB

Applications that use I2P datagrams (either raw or repliable ones) can essentially be thought +of in terms of UDP - the datagrams are unordered, best effort, and connectionless - but unlike +UDP, applications don't need to worry about MTU detection and can simply fire off 32KB datagrams +(31KB when using the repliable kind). For many applications, 32KB of data is sufficient for an +entire request or response, allowing them to transparently operate in I2P as a UDP-like +application without having to write fragmentation, resends, etc.

Integration techniques

There are four means of sending data over I2P, each with their own pros and cons.

SAM

SAM is the Simple Anonymous Messaging protocol, allowing an +application written in any language to talk to a SAM bridge through a plain TCP socket and have +that bridge multiplex all of its I2P traffic, transparently coordinating the encryption/decryption +and event based handling. SAM supports three styles of operation:

I2PTunnel

The I2PTunnel application allows applications to build specific TCP-like tunnels to peers +by creating either I2PTunnel 'client' applications (which listen on a specific port and connect +to a specific I2P destination whenever a socket to that port is opened) or I2PTunnel 'server' +applications (which listen to a specific I2P destination and whenever it gets a new I2P +connection it outproxies to a specific TCP host/port). These streams are 8bit clean and are +authenticated and secured through the same streaming library that SAM uses, but there is a +nontrivial overhead involved with creating multiple unique I2PTunnel instances, since each have +their own unique I2P destination and their own set of tunnels, keys, etc.

ministreaming and datagrams

For applications written in Java, the simplest way to go is to use the libraries that the SAM +bridge and I2PTunnel applications use. The streaming functionality is exposed in the 'ministreaming' +library, which is centered on the +I2PSocketManager, +the I2PSocket, and the +I2PServerSocket.

For applications that want to use repliable datagrams, they can be built with the +I2PDatagramMaker +and parsed on the receiving side by the +I2PDatagramDissector. +In turn, these are sent and received through an + +I2PSession.

Applications that want to use raw datagrams simply send directly through the I2PSession's +sendMessage(...) +method, receiving notification of available messages through the +I2PSessionListener and +then fetching those messages by calling +receiveMessage(...). + +

I2CP

I2CP itself is a language independent protocol, but to implement an I2CP library in something other +than Java there is a significant amount of code to be written (encryption routines, object marshalling, +asynchronous message handling, etc). While someone could write an I2CP library in C or something else, +it would most likely be more useful to write a C SAM library instead.

Bounties

While we always gratefully accept any contributions of code, +documentation, and the like, there are other ways to help I2P move +forward. As with any open source project, our goals would be achieved more +rapidly if we were able to support all of our contributors to work on +I2P full time. However, as with any open source project, thats not a +possibility. Instead, we are making use of a bounty system, whereby +anyone can get support for working on something that people want +implemented, and people who want to contribute to I2P can be assured that +their support goes to what they care about.

We are also keeping open the ability for people who want to support I2P +but don't have strong feelings about the bounties available. Those people +can simply put their trust in the I2P team to do what we feel is best by +donating to a catch-all general fund that will be used as deemed +necessary - allocated to various bounties, covering incidentals (hosting, +etc), and the like.

Current bounties

^* Dev lists anyone who may already be working on the bounty - collaboration is preferred, so if you're interested in working on it, please contact one of the people listed!

General fund balance

CVS

Donate

Thank you for your interest in contributing to I2P! The details of how you can make your contribution are provided below:

e-gold

PayPal

FAQ

What is I2P?

I2P is a generic anonymous and secure peer to peer communication layer. It is a network that sits on +top of another network (in this case, it sits on top of the internet). It is responsible for delivering +a message anonymously and securely to another location. More tech details are +available

What does that mean?

It means that you can do things anonymously and host services anonymously from your computer. +You will need to use programs that are designed to work with I2P, though in some cases you can use +regular internet programs with I2P by creating something called an +I2PTunnel

What is the difference between I2P and the internet?

Data transferred via I2P is anonymous and encrypted. Regular internet traffic is not +(although it can be encrypted). If you set up a web page using I2P, nobody will know who +you are. If you browse a web page using I2P, nobody will know who you are. If you transfer +files using I2P, nobody will know who you are.

Whats an "eepsite"?

An eepsite is a website that is hosted anonymously - you can access it by setting your web browser's HTTP proxy to use the web proxy (typically it listens on localhost port 4444), +and browsing to the site.

Can I browse the web with I2P?

Yes - the I2PTunnel eepproxy includes a hook to use an anonymously hosted outbound proxy +(squid.i2p). If you have your browser set to use the web proxy, if you type +http://google.com/ your request will be routed through I2P to the outbound proxy.

How anonymous is I2P anyway?

I2P is working to support militant grade anonymity, but we're not there yet. You should not +use I2P if you need your anonymity - there are likely bugs and perhaps other issues, and it +has not gone through sufficient peer review. However, we're confident that we'll get to the point +that we can provide anonymity strong enough even for militantly subversive political action (so it +should be fine for you to chat online with your friends)

An important point to note is that I2P does not provide anonymity or security of content +after it is transferred - you can still download and run a virus, or even submit your full name +and bank account numbers on an eepsite. I2P only tries to provide communication security and anonymity - +what you say or do is up to you.

How does I2P protect itself from denial of service attacks?

+ For this too, there are several answers. Short summary is "the best it can". + Briefly, I2P attempts to defend against several forms of denial of service + attack, all without centralized coordination. For applications using I2P, + the computer they are located on is not exposed to the public, so the + standard denial of service attack cannot be directly mounted against them + (ala ping floods, etc). Instead, attackers are forced to go after the + gateways to that application's inbound tunnels - of which there can be many + at any given time. Each gateway also has its own limits for how many messages + and/or bytes it agrees to send down the tunnel. The application itself + periodically tests these tunnels to make sure they're still reachable and + usable, so if one of them is taken out by an IP level attack of any kind, + it will know and rebuild its leases, specifying new gateways. +

+ To prevent individual users from consuming excessive resources (registering + too many tunnels, sending too many messages, looking up too many entries in + the network database, and creating too many router and destination identities), + various messages and identities have a certificate attached to them. Currently + these certificates are blank, but down the line they will be filled with + IIP Wiki: HashCash - a computationally expensive collision based on the contents of the + message or identity. They can also be filled with other certificates as deemed + necessary (e.g. a blinded certificate from an anonymous certificate authority, + a receipt for real currency payments, etc). It is also believed that through this + certificate attachment system I2P will be able to overcome the sybil attack.
+ +

+ Other denial of service attacks include creating a few thousand high quality + I2P routers, running them for a week, and then taking them all offline. This + indeed may force the creation of islands within the network, but the underlying + Network Database is built off of a modified Kademlia, + which should allow the network to recover with minimal overhead (though, of course, + if a router has literally no other peers left after the bad ones leave, that router will + need to 'reseed' - fetch a reference to another router through some other mechanism). +

I have a question!

Great! Please leave a comment and we'll include it here (with the answer, hopefully)

Hall of Fame

Big thanks go to the following people who have donated to bounties or the general fund!

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Contributor	Amount	Bounty
Pseudonym	$60.00 USD	Upgrade of transport protocol
duck	$50.00 USD	MyI2P
wilde	$60.00 USD	MyI2P
eco	$30.01 USD	General fund
Jeff Teitel	$50.00 USD	General Fund
hypercubus	$10.00 USD	General Fund
eco	$23.45 USD	General fund
duck	0.0186g gold	General fund

I2P

diff --git a/pages/home.html b/pages/home.html new file mode 100644 index 00000000..286e6166 --- /dev/null +++ b/pages/home.html @@ -0,0 +1 @@ +

Welcome on I2P.net

diff --git a/pages/how_elgamalaes.html b/pages/how_elgamalaes.html new file mode 100644 index 00000000..ce63b38e --- /dev/null +++ b/pages/how_elgamalaes.html @@ -0,0 +1,78 @@ +

ElGamal / AES+SessionTag

+Within I2P, various messages are encrypted, but we don't want anyone to know +to whom or from whom it is bound, so we can't just toss a "to" or "from" address. +In addition, messages are not delivered in order (or reliably), so we can't simply +ElGamal encrypt the first message and AES the subsequent messages. The alternative +of ElGamal encrypting each individual message is daunting in light of the message +frequency desired. Instead, we take each message and evaluate whether it fits into +the three possible conditions:

+ +

its ElGamal encrypted to us
its AES encrypted to us
its not encrypted to us

+If its ElGamal encrypted to us, the message is considered a new session, and +is encrypted per encryptNewSession(...) in +[ElGamalAESEngine] +as follows -

+ +

An initial ElGamal block, encrypted as before:

+ +

+ |_______1_______2_______3_______4_______5_______6_______7_______8
+ |   32 byte session key
+ |
+ |
+ |                                                               |
+ |   32 byte pre-IV (first 16 bytes of H(pre-IV) == IV)
+ |
+ |
+ |                                                               |
+ | (158 bytes of random data)
+ |                              ...
+ |                                                               |
+

+ +

Followed by the following, AES encrypted as before, +using the session key and IV from the header:

+ +

+ |_______1_______2_______3_______4_______5_______6_______7_______8
+ | # session tags| that many sessionTags (32 byte random numbers)
+ |                              ...
+ |               |  size of the payload (bytes)  | H(payload)
+ |
+ |
+ |
+ |                                               | flag  |payload
+ |                              ...
+ |                                                               |
+ | random bytes leaving the total AES block (size % 16 == 0)     |
+
+

+ +

If the flag is 0x01, it is followed by a new session key, replacing +the old one.

+ +

The session tags delivered successfully are remembered for a +brief period (30 minutes currently) until they are used (and discarded). +They are used by packaging in a message that is not preceeded by an +ElGamal block. Instead, it is encrypted per encryptExistingSession(...) in +[ElGamalAESEngine] +as follows -

+ +

+ |_______1_______2_______3_______4_______5_______6_______7_______8
+ | session tag (32 byte random number previously delivered and 
+ |    not yet expired or used).  the session tag also serves as
+ |    the pre-IV (the first 16 bytes of H(sessionTag) == IV)
+ |                                                               |
+

+ +

Followed by the AES encrypted block above (2 byte # session tags, +that many session tags, sizeof(payload), H(payload), flag, payload, +random padding).

diff --git a/pages/how_intro.html b/pages/how_intro.html new file mode 100644 index 00000000..62f83de3 --- /dev/null +++ b/pages/how_intro.html @@ -0,0 +1,150 @@ +

Intro

I2P is an effort to build, deploy, and maintain a network to support secure and anonymous +communication. People using I2P are in control of the tradeoffs between anonymity, reliability, +bandwidth usage, and latency. There is no central point in the network on which pressure can be +exerted to compromise the integrity, security, or anonymity of the system. The network supports +dynamic reconfiguration in response to various attacks, and has been designed to make use of +additional resources as they become available. Of course, all aspects of the network are open +and freely available.

+ +

Unlike many other anonymizing networks, I2P doesn't try to provide anonymity by hiding the +originator of some communication and not the recipient, or the other way around. I2P is designed +to allow peers using I2P to communicate with each other anonymously – both sender and recipient +are unidentifiable to each other as well as to third parties. For example, today there are both +in-I2P web sites (allowing anonymous publishing / hosting) as well as HTTP proxies to the normal +web (allowing anonymous web browsing). Having the ability to run servers within I2P is essential, +as it is quite likely that any outbound proxies to the normal internet will be monitored, disabled, +or even taken over to attempt more malicious attacks.

+ +

The network itself is message oriented - it is essentially a secure and anonymous IP layer, +where messages are addressed to cryptographic keys (Destinations) and can be significantly larger +than IP packets. Some example uses of the network include "eepsites" (webservers hosting normal web +applications within I2P), a BitTorrent port ("I2PSnark"), +or a distributed data store. With the help of mihi's I2PTunnel application, +we are able to stream traditional TCP/IP applications over I2P, such as SSH, irc, a squid proxy, and +even streaming audio. Most people will not use I2P directly, or even need to know they're using it. +Instead their view will be of one of the I2P enabled applications, or perhaps as a little controller +app to turn on and off various proxies to enable the anonymizing functionality.

+ +

An essential part of designing, developing, and testing an anonymizing network is to define the +threat model, since there is no such thing as "true" anonymity, just +increasingly expensive costs to identify someone. Briefly, I2P's intent is to allow people to communicate +in arbitrarily hostile environments by providing militant grade anonymity, mixed in with sufficient cover +traffic provided by the activity of people who require less anonymity. This includes letting Joe Sixpack +chat with his buddies without anyone listening in, Jane Filetrader to share files knowing that large +corporations cannot identify her, as well as Will Whistleblower to publish sensitive documents - +all on the same network, where each one's messages are essentially indistinguishable from the +others.

+ +

Why?

There are a multitude of fantastic reasons why we need a system to support +anonymous communication, and everyone has their own personal rationale. There have are many +other efforts working on finding ways to provide varying degrees of +anonymity to people through the Internet, but we could not find any that met our needs or threat +model.

+ +

How?

+ +

The network at a glance is made up of a set of nodes (“routers”) with a number of unidirectional +inbound and outbound virtual paths ("tunnels", as outlined on Tunnel Routing). +Each router is identified by a cryptographic RouterIdentity which is typically long lived. These routers +communicate with each other through existing transport mechanisms (e.g. TCP, UDP, PHTTP), passing various +messages. Client applications have their own cryptographic identifier ("Destination") which enables it +to send and receive messages. These clients can connect to any router and authorize the temporary +allocation ("lease") of some tunnels that will be used for sending and receiving messages through the +network. I2P has its own internal network database (using a modification of +the Kademlia algorithm) for distributing routing and contact information.

+ +

The following illustration is a simplistic view regarding how tunnels, routers, and destinations +are associated, with a pair of inbound tunnels (pink lines) leading towards the router which the +destination is connected to (little "a"), with a set of outbound tunnels (green lines) leading away +from that router. The gateway for each of the inbound tunnels (big "A"s) are identified in the lease +as published in the network database. Additional topological information can be found +here.

+ +

The network topology

+ +

Messages send from one Destination to another are (typically) sent through a pair of tunnels - first +they go out one of the local router's outbound tunnels with instructions specifying that the outbound +tunnel's end point forward the message to one of the target Destination's inbound tunnel gateways, +which, on receiving the message, passes it down the tunnel to the recipient. Various mechanisms are +used to secure these tunnel routed messages, as described tunnel routing. +In addition, they can be sent in parallel down multiple tunnels, with the last router discarding +duplicates.

+ +

I2P Tunnel sending

+ +

Some of the messages sent in the network (such as those used to manage tunnels, publish some Leases, +and deliver long lived end to end messages) may be instead are sent via +garlic routing. Inspired by a subsection for future works written by +Michael Freedman within Roger Dingledine's freehaven +thesis, and with some similarities to +onion routing. I2P's garlic routing allows multiple messages +("cloves") to be wrapped inside a single message ("garlic") so that only the intended recipient can +determine how many cloves are contained as well as how those cloves should be processed.

+ +

To deal with a wide range of attacks, I2P is fully distributed with no centralized resources - and +hence there are no directory servers keeping statistics regarding the performance and reliability of +routers within the network. As such, each router must keep and maintain profiles of various routers +and is responsible for selecting appropriate peers to meet the anonymity, performance, and reliability +needs of the users, as described in the peer selection pages

+ +

The network itself makes use of a significant number of cryptographic techniques and altorithms - +a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode with PKCS#5 padding, +1024bit DSA signatures, SHA256 hashes, 2048bit Diffie-Hellman negotiated connections with station to +station authentication, and ElGamal / AES+SessionTag.

+ +

Content sent over I2P is encrypted through three or four layers - end to end encryption (absolutely +no routers get the plaintext, ever), garlic encryption (used to verify the delivery of the message to +the recipient), tunnel encryption (all messages passing through a tunnel is encrypted by the tunnel +gateway to the tunnel endpoint), and interrouter transport layer encryption (e.g. the TCP transport +uses AES256 with ephemeral keys):

+ +

end to end layered encryption

+ +

The specific use of these algorithms are outlined elsewhere

+ +

The two main mechanisms for allowing people who need militant grade anonymity use the network are +explicitly delayed garlic routed messages and more comprehensive tunnels to include support for pooling +and mixing messages. These are currently planned for release 3.0, but garlic routed messages with no +delays and FIFO tunnels are currently in place. Additionally, the 2.0 release will allow people to set +up and operate behind restricted routes (perhaps with trusted peers), as well as the deployment of more +flexible and anonymous transports.

+ +

Some questions have been raised with regards to the scalability of I2P, and reasonably so. There +will certainly be more analysis over time, but peer lookup and integration should be bounded by +O(log(N)) due to the network database's algorithm, while end to end +messages should be O(log(1)) (scale free), since messages go out K hops through the outbound +tunnel and another K hops through the inbound tunnel - the size of the network (N) bears no impact.

+ +

When?

I2P initially began in Feb 2003 as a proposed modification to +freenet to allow it to use alternate transports, such as +JMS, then grew into its own as an +'anonCommFramework' in April 2003, turning into I2P in July, with code being cut in earnest in August, +reaching the 0.2 release in September and 0.3 in March. I2P is currently moving forward according to +the roadmap.

+ +

The network itself is not ready for general use, and should not be used by those who need anonymity +until it has been met with sufficient peer review.

+ +

Who?

We have a small team spread around several continents, working to advance different +aspects of the project. We are very open to other developers who want to get involved and anyone else +who would like to contribute in other ways, such as critiques, peer review, testing, writing I2P enabled +applications, or documentation. The entire system is open source - the router and most of the SDK are +outright public domain with some BSD and Cryptix licensed code, while some applications like I2PTunnel +and I2PSnark are GPL. Almost everything is written in Java (1.3+), though some third party applications +are being written in Python. The code generally works on Kaffe, and +we are hoping to get it working on GCJ sooner rather than later.

+ +

Where?

Anyone interested should subscribe to the mailing list and +join us on the irc channel #i2p (hosted concurrently on IIP, +irc.freenode.net, irc.duck.i2p, and irc.baffled.i2p). Weekly development meetings are held there every +Tuesday at 9pm GMT with archives available.

+ +

The current source is available through an anonymous CVS repository

+cvs -d :pserver:anoncvs@i2p.net/cvsroot co i2p

with the password anoncvs.

diff --git a/pages/how_threatmodel.html b/pages/how_threatmodel.html new file mode 100644 index 00000000..b1b80231 --- /dev/null +++ b/pages/how_threatmodel.html @@ -0,0 +1,125 @@ +

Threatmodel

+There are a great many other applications and projects working on anonymous +communication and I2P has been inspired by much of their efforts. This is not +a comprehensive list of anonymity resources - both freehaven's +Anonymity Bibliography +and GNUnet's related projects serve +that purpose well. That said, a few systems stand out for further comparison:

+ +

Morphmix and Tarzan +
TOR / Onion Routing +
Mixminion / Mixmaster +
Freenet +
JAP +

+ +

Morphmix and Tarzan

+ +[Morphmix] + [Tarzan] + +

+Morphmix and Tarzan are both fully distributed, peer to peer networks of +anonymizing proxies, allowing people to tunnel out through the low latency +mix network. Morphmix includes some very interesting collusion detection +algorithms and Sybil defenses, while Tarzan makes use of the scarcity of IP +addresses to accomplishs the same. The two primary differences between +these systems and I2P are related to I2P's threat model +and their out-proxy design (as opposed to providing both sender and receiver +anonymity). There is source code available to both systems, but we are not aware +of their use outside of academic environments.

+Stealing quite directly from the Tarzan paper, the following includes a quick +comparison of Tarzan, Crowds, Onion Routing (OR), and I2P:

+ +

TOR / Onion Routing

+ +[TOR] + [Onion Routing] +

+TOR and Onion Routing are both anonymizing proxy networks, allowing people +to tunnel out through their low latency mix network. The two primary +differences between TOR / OnionRouting and I2P are again related to differences +in the threat model and the out-proxy design (though TOR is working to provide +redevous points within the mix network, which will provide recipient anonymity). +In addition, these networks take the directory based approach - providing a +centralized point to manage the overall 'view' of the network, as well as gather +and report statistics, as opposed to I2P's distributed + +network database and peer selection.

+ +

On the technical side, there are 5 main differences between TOR and I2P:

TOR is centrally managed (trusted directories, only some people fully participate + in the network with cover traffic) while I2P is fully distributed. This has serious + anonymity implications for people using TOR that are not one of the TOR nodes, + since a powerful attacker could determine your identity, or coerce the maintainer + of TOR's directory server to include untrustworthy nodes.
TOR is circuit based (with reliable, ordered, bidirectional tunnels), while I2P + is packet based (with unreliable, unordered, unidirectional tunnels). As with the + TCP/IP separation, I2P optionally adds TCL-like functionality on top of the packet + based network by means of mihi's ministreaming library.
TOR is low latency, while I2P is variable latency (both ASAP and stop+go). This will + allow I2P to provide a higher level of anonymity by blending the anonymity set of + different user bases together - for example, filesharing users and militants look + the same, though make use of different techniques to balance their own anonymity + and security needs)
TOR is IP addressed, relying on the security of the IP layer for authenticating + and securing the message delivery, while I2P is cryptographically addressed.
TOR is written in C on *nix (windows port w/ cygwin?), while I2P is written in + Java and tested on *nix, windows, and macs

+ +

Mixminion / Mixmaster

+ +[Mixminion] + [Mixmaster] + +

+Mixminion and Mixmaster are networks to support anonymous email against a very +powerful adversary. I2P aims to provide an adequate means to meet their threat +model as we reach I2P 3.0 along side the needs of low latency users, providing +a significantly larger anonymity set. As with TOR and Onion Routing above, +both Mixminion and Mixmaster take the directory based approach as well.

+ +

Freenet

+ +[Freenet] +

+Freenet is a fully distributed, peer to peer anonymous publishing network. +As such, generic anonymous communication over it requires the use of the global +blackboard model - storing data somewhere that the recipient will then check +for a message. Freenet also does not support the concept of user defined delays - +it stores and fetches data as quickly as it can, rather than queueing up, pooling, +delaying, and mixing the data, leaving a hole with regards to long term intersection +attacks. In addition, there seem to be some performance issues that can arguably +be attributed to the global blackboard model which will likely rule out interactive +low latency communication.

+ +

JAP

+ +[JAP] + +

+JAP (Java Anonymous Proxy) is a network of mix cascades for anonymizing web requests, +and as such it has a few centralized nodes (participants in the cascade) that blend +and mix requests from clients through the sequence of nodes (the cascade) before +proxying out onto the web. The scope, threat model, and security is substantially +different from I2P, but for those who don't require significant anonymity but still +are not satisfied with an Anonymizer-like service, JAP is worth reviewing. One +caution to note is that anyone under the jurisdiction of the German courts may want +to take care, as the German Federal Bureau of Criminal Investigation (FBCI) has has +successfully mounted an +[attack] +on the network. Even though the method of this attack was later found to be illegal +in the German courts, the fact that the data was successfully collected is the +concern. Courts change their minds based upon circumstance, and this is evidence that +if a government body or intelligence agency wanted to, they could gather the data, even +if it may be found inadmissible in some courts later) +

diff --git a/pages/jbigi.html b/pages/jbigi.html new file mode 100644 index 00000000..94507fe4 --- /dev/null +++ b/pages/jbigi.html @@ -0,0 +1,52 @@ +

jbigi

Using JNI (Java Native Interface), a bit of C code +(thanks ughabugha!), a little manual work and +a piece of chewinggum it is possible to make the public key cryptography +quite a bit faster.

+ + +

Requirements

This works on Linux, and with a few changes in build.sh probably also on other +platforms. FreeBSD has also been reported to work too. On Kaffee the speedup is very +small, because it already uses native BitInteger internally. Blackdown seems to cause +strange errors. Because you are going to do compilation, you need JDK; JRE won't work.

+ +

The required code is available in CVS and the latest source tarball.

+ +

The GNU MP Bignum library (libgmp) needs to be installed, if it isn't included in +your OS / distribution or installed already, it can be received from +http://www.swox.com/gmp/. Even if you have already +installed it as binary, it might still be worth a try to compile GMP yourself, since then +it will be able to use the specific instructions of your processor.

+ +

Step-by-step instructions

Look on http://localhost:7655/routerStats.html +to see what the values for crypto.elGamal.decrypt and crypto.elGamal.encrypt are. +Copy this somewhere so you can compare it later on.
Get the latest sourcecode
Inside the source tree change directory to: core/c
Take a look at build.sh, if your JAVA_HOME environment variable is set and +you are using Linux then it might just work. Otherwise change the settings.
Run build.sh
+A file named libjbigi.so should be created in the current directory. +If this doesn't happen and/or you get errors then please report them.
+ +Also some tests are done. Read the final lines of output for some additional +info, it will be something like this: +
```
+native run time:  5842ms ( 57ms each)
+java run time:   41072ms (406ms each)
+native = 14.223802103622907% of pure java time
+
```
+If the native is indeed 5-7x faster then it looks all good. If not, please report.
Copy libjbigi.so to your i2p directory
Restart your I2P programs.
On http://localhost:7655/routerStats.html +the crypto.elGamal.decrypt and crypto.elGamal.encrypt should be a lot faster.

+ +

Feedback is appreciated

diff --git a/pages/licenses.html b/pages/licenses.html new file mode 100644 index 00000000..cb982116 --- /dev/null +++ b/pages/licenses.html @@ -0,0 +1,192 @@ +

Licenses

As required by our threat model (among other reasons), the +software developed to support the anonymous communication +network we call I2P must be freely available, open source, +and user modifiable. To meet this criteria, we make use of +a variety of legal and software engineering techniques so +as to remove as many barriers to entry for those considering +making use of or contributing to the I2P effort.

+ + +

While the information below may be more confusing than just simply +stating "I2P is BSD", "I2P is GPL", or "I2P is public domain", +the short answer to the question "How is I2P licensed?" is this:

+ +

All software bundled in the I2P distributions will allow:

use without fee
use with no restrictions on how, when, where, why, or by whom is running it
access to the source code without fee
modifications to the source

+ +

Most of the software guarantees much more - the ability of anyone to +distribute the modified source however they choose. However, not all of the +software bundled provides this freedom - the GPL restricts the ability of +developers who wish to integrate I2P with their own applications that are not +themselves open source applications. While we applaud the noble goals of +increasing the resources in the commons, I2P is best served by removing any +barriers that stand in the way of its adoption - if a developer considering whether +they can integrate I2P with their application has to stop and check with their lawyer, +or conduct a code audit to make sure their own source can be released as GPL-compatible, +we lose out.

+ +

Component licenses

+ +

The I2P distribution contains several resources, reflecting the partitioning of +the source code into components. Each component has its own license, which all +developers who contribute to it agree to - either by explicitly declaring the release +of code committed under a license compatible with that component, or by implicitly +releasing the code committed under the component's primary license. Each of these +components has a lead developer who has the final say as to what license is compatible +with the component's primary license, and the I2P project manager has the final say as +to what licenses meet the above four guarantees for inclusion in the I2P distribution.

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Component	CVS path	Resource	Primary license	Alternate licenses	Lead developer
I2P SDK	core	i2p.jar	Public domain	BSD + Cryptix + MIT	jrandom
I2P Router	router	router.jar	Public domain	BSD + + Cryptix + MIT	jrandom
ministreaming	apps/ministreaming	mstreaming.jar	BSD	Public domain + Cryptix + MIT	mihi
I2PTunnel	apps/i2ptunnel	i2ptunnel.jar	GPL + exception	Public domain + + BSD + Cryptix + MIT	mihi
HTTPTunnel	apps/httptunnel	httptunnel.jar	GPL + exception	Public domain + BSD + Cryptix + + MIT	mihi
SAM bridge	apps/sam	i2psam.jar	GPL	Public domain + Cryptix + BSD + MIT	aum
phttprelay	apps/phttprelay	phttprelay.war	Public domain	Cryptix + + BSD + MIT	jrandom
Installer	installer	install.jar, guiinstall.jar	Public domain	GPL + exception + BSD + Cryptix + MIT	jrandom

+ +

GPL + java exception

While it may be redundant, just for clarity the GPL'ed +code included within I2PTunnel must be released under the GPL with an additional "exception" explicitly +authorizing the use of Java's standard libraries:

+ +

+In addition, as a special exception, XXXX gives permission to link +the code of this program with the proprietary Java implementation +provided by Sun (or other vendors as well), and distribute linked +combinations including the two. You must obey the GNU General +Public License in all respects for all of the code used other than +the proprietary Java implementation. If you modify this file, you +may extend this exception to your version of the file, but you are +not obligated to do so. If you do not wish to do so, delete this +exception statement from your version. +

+ +

+All source code under each component will by default be licensed under the primary license, +unless marked otherwise in the code. All of the above is summary of the license terms - +please see the specific license for the component or source code in question for authoritative +terms. Component CVS locations and resource packaging may be changed if the repository +is reorganized.

+ +

CVS commit priviliges

All developers must explicitly agree with the above terms to receive commit access to I2P's +CVS repository. That means that they affirm that:

unless marked otherwise, all code they commit is implicitly licensed under the component's + primary license
if specified in the source, the code may be explicitly licensed under one of the component's + alternate licenses
they have the right to release the code they commit under the terms they are committing it

+ +

If anyone is aware of any instances where the above conditions are not met, please contact the +component lead and/or the I2P project manager with further information.

diff --git a/pages/minwww.html b/pages/minwww.html new file mode 100644 index 00000000..23c03a08 --- /dev/null +++ b/pages/minwww.html @@ -0,0 +1,115 @@ +

MinWWW

+Here's an outline and rationale for a minimal WWW proxy app for use +over I2P. + +

+HTTP operation over I2P using I2PTunnel. When the base SocketLibrary +is out, the only significant difference will be the 'wrapRequest' and +'unwrapRequest' will functionally be placed in the socketLibrary, not +in the router (but later versions of the SocketLibrary will be able to +use selective ACK and large window sizes, allowing more ACKs to be +skipped) +

+---BROWSER--->-I2PTUNNEL--->-ROUTERA--->-ROUTERB--->-I2PTUNNEL--->-HTTPD----------
+ 1: openCon
+ 2:            requestCon  
+ 3:                         wrapRequest
+ 4:                                    unwrapRequest
+ 5:                         receiveACK               receiveCon
+ 6:            sentSuccess                           sendSYN
+ 7:                                     wrapRequest
+ 8:                       unwrapRequest
+ 9:            receiveSYN               receiveACK
+10: "GET /"                                          sentSuccess
+11:            sendData
+12:                         wrapRequest
+13:                                    unwrapRequest
+14:                         receiveACK               receiveData
+15:            sentSuccess                                        "GET /"
+16:                                                               "HTTP 200\n\nHi"
+17:                                                  sendData
+18:                                     wrapRequest
+19:                       unwrapRequest
+20:            receiveData              receiveACK
+21: "HTTP 200\n\nHi"                                 sentSuccess
+22: closeCon
+23:            sendClose
+24:                         wrapRequest
+25:                                    unwrapRequest
+26:                         receiveACK               receiveClose
+27:            sentSuccess                           
+
+

+An optimized form, designed to handle only 128KB [1] files and pages, can +operate significantly faster: +

+   BROWSER --> MinWWW   --> ROUTERA --> ROUTERB --> MinWWW    --> HTTPD
+ 1: openCon    
+ 2:            opened
+ 3: "GET /"    
+ 4:            sendData
+ 5:                         forward
+ 6:                                     receive
+ 7:                                                 receiveData
+ 8:                                                               "GET /"
+ 9:                                                               "HTTP 200\n\nHi"
+10:                                                 sendData
+11:                                     forward
+12:                         receive
+13:            receiveData
+14: "HTTP 200\n\nHi"
+15: closeCon
+16:            closed
+
+

+The difference in network load and latency is significant - this is essentially +a UDP version of HTTP. On the normal web, we can't really do that, since most +HTTP requests and responses are orders of magnitude larger than UDP packets +functionally support, but in I2P, messages can be large. The savings for the +network load comes from the fact that we don't need to send any ACK messages - +rather than the earlier wrap/unwrap request (that bundles a DataMessage with +a DeliveryStatusMessage to provide guaranteed delivery), the MinWWW proxy deals +with resends (if necessary - in I2PTunnel today, there are no resends). +

+The data that the MinWWW proxy and server need to wrap is trivial - when the +proxy wants to send "GET /", it prepends it with the I2P Destination sending +the request, followed by a 4 byte request ID. The MinWWW server receives those +requests, contacts the appropriate HTTPD, sends the request, waits for the +response, and sends a reply to the MinWWW proxy containing the response, prefixed +with the original request ID. That response is taken and passed back to the +browser and the connection is closed. +

+In addition, the MinWWW proxy can choose the MinWWW server to use from a list, +going through some round robin or other algorithm, so that there are multiple +outproxies merged transparently. The bandwidth required for running one of +these outproxies is also greatly reduced, since it will only handle 128KB files +(aka no one is going to be downloading porn, warez, etc). +

+The functionality /is/ limited, but 128KB of data is a lot for a single HTTP +request or response. The above diagrams are also unrealistic in their hops - +ROUTERA will really never talk directly to ROUTERB. ROUTERA will send each +of the messages through two additional outbound routers, then forwarded to +two additional inbound routers to ROUTERB, so the lag there is significant - +while the above only saves 11 steps, 8 of those steps need to traverse the +entire tunnel path (4+ remote hops each time when tunnels are 2 remote hops +in each stretch), leaving MinWWW with only two full traversals (one for the +request, one for the response), instead of 10. + +

+Implementing the MinWWW proxy and server should be fairly easy - read an HTTP +request from the client fully (perhaps only start out with HTTP GET, leaving +HTTP POST for later), wrap the message, and wait for the response. The server +in turn simply needs to parse the request to either open a socket or URL, +send the request, wait for the response, and send it back through the network. +If someone were to implement this, it would be Good :) +

+[1] Why 128KB files? Currently I2CP allows functionally arbitrary message size, +but thats going to be going away since it involves either excessive memory +overhead on intermediary routers, or additional implementation details to +handle. I2PTunnel is currently limited to 128KB and hasn't been a burden, +so perhaps it could be increased to 256KB when the I2CP spec is updated) + + diff --git a/pages/performance.html b/pages/performance.html new file mode 100644 index 00000000..ef8429bc --- /dev/null +++ b/pages/performance.html @@ -0,0 +1,61 @@ +

Performance

Probably one of the most frequent things people ask is "how fast is I2P?", and no one seems to like the answer - "it depends". After trying out I2P, the next thing they ask is "will it get faster?", and the answer to that is a most emphatic yes.

+ + +

There are a few major techniques that can be done to improve the percieved performance of I2P - some of the following are CPU related, others bandwidth related, and others still are protocol related. However, all of those dimensions affect the latency, throughput, and percieved performance of the network, as they reduce contention for scarce resources. This list is of course not comprehensive, but it does cover the major ones that I see.

+ +

Native math

+ +

When I last profiled the I2P code, the vast majority of time was spent within one function: java.math.BigInteger's modPow. Rather than try to tune this method, we'll call out to GNU MP - an insanely fast math library (with tuned assembler for many architectures). (Editor: see NativeBigInteger for faster public key cryptography)

+ +

ughabugha and duck are working on the C/JNI glue code, and the existing java code is already deployed with hooks for that whenever its ready. Preliminary results look fantastic - running the router with the native GMP modPow is providing over a 800% speedup in encryption performance, and the load was cut in half. This was just on one user's machine, and things are nowhere near ready for packaging and deployment, yet.

+ +

Garlic wrapping a "reply" LeaseSet

+ +

This algorithm tweak will only be relevent for applications that want their peers to reply to them (though that includes everything that uses I2PTunnel or mihi's ministreaming lib):

+ +

Currently, when Alice sends Bob a message, when Bob replies he has to do a lookup in the network database - sending out a few requests to get Alice's current LeaseSet. If he already has Alice's current LeaseSet, he can instead just send his reply immediately - this is (part of) why it typically takes a little longer talking to someone the first time you connect, but subsequent communication is faster. What we'll do - for clients that want it - is to wrap the sender's current LeaseSet in the garlic that is delivered to the recipient, so that when they go to reply, they'll always have the LeaseSet locally stored - completely removing any need for a network database lookup on replies. Sure, this trades off a bit of the sender's bandwidth for that faster reply (though overall network bandwidth usage decreases, since the recipient doesn't have to do the network database lookup).

+ +

Better peer profiling and selection

+ +

Probably one of the most important parts of getting faster performance will be improving how routers choose the peers that they build their tunnels through - making sure they don't use peers with slow links or ones with fast links that are overloaded, etc. In addition, we've got to make sure we don't expose ourselves to a sybil attack from a powerful adversary with lots of fast machines.

+ +

Network database tuning

+ +

We're going to want to be more efficient with the network database's healing and maintenance algorithms - rather than constantly explore the keyspace for new peers - causing a significant number of network messages and router load - we can slow down or even stop exploring until we detect that there's something new worth finding (e.g. decay the exploration rate based upon the last time someone gave us a reference to someone we had never heard of). We can also do some tuning on what we actually send - how many peers we bounce back (or even if we bounce back a reply), as well as how many concurrent searches we perform.

+ +

Longer SessionTag lifetime

+ +

The way the ElGamal/AES+SessionTag algorithm works is by managing a set of random one-time-use 32 byte arrays, and expiring them if they aren't used quickly enough. If we expire them too soon, we're forced to fall back on a full (expensive) ElGamal encryption, but if we don't expire them quickly enough, we've got to reduce their quantity so that we don't run out of memory (and if the recipient somehow gets corrupted and loses some tags, even more encryption failures may occur prior to detection). With some more active detection and feedback driven algorithms, we can safely and more efficiently tune the lifetime of the tags, replacing the ElGamal encryption with a trivial AES operation.

+ +

Longer lasting tunnels

+ +

The current default tunnel duration of 10 minutes is fairly arbitrary, though it "feels ok". Once we've got tunnel healing code and more effective failure detection, we'll be able to more safely vary those durations, reducing the network and CPU load (due to expensive tunnel creation messages).

+ +

Adjust the timeouts

+ +

Yet another of the fairly arbitrary but "ok feeling" things we've got are the current timeouts for various activities. Why do we have a 60 second "peer unreachable" timeout? Why do we try sending through a different tunnel that a LeaseSet advertises after 10 seconds? Why are the network database queries bounded by 60 or 20 second limits? Why are destinations configured to ask for a new set of tunnels every 10 minutes? Why do we allow 60 seconds for a peer to reply to our request that they join a tunnel? Why do we consider a tunnel that doesn't pass our test within 60 seconds "dead"?

+ +

Each of those imponderables can be addressed with more adaptive code, as well as tuneable parameters to allow for more appropriate tradeoffs between bandwidth, latency, and CPU usage.

+ +

More efficient TCP rejection

+ +

At the moment, all TCP connections do all of their peer validation after going through the full (expensive) Diffie-Hellman handshaking to negotiate a private session key. This means that if someone's clock is really wrong, or their NAT/firewall/etc is improperly configured (or they're just running an incompatible version of the router), they're going to consistently (though not constantly, thanks to the shitlist) cause a futile expensive cryptographic operation on all the peers they know about. While we will want to keep some verification/validation within the encryption boundary, we'll want to update the protocol to do some of it first, so that we can reject them cleanly without wasting much CPU or other resources.

+ +

Adjust the tunnel testing

+ +

Rather than going with the fairly random scheme we have now, we should use a more context aware algorithm for testing tunnels. e.g. if we already know its passing valid data correctly, there's no need to test it, while if we haven't seen any data through it recently, perhaps its worthwhile to throw some data its way. This will reduce the tunnel contetion due to excess messages, as well as improve the speed at which we detect - and address - failing tunnels.

+ +

Compress some data structures

+ +

The I2NP messages and the data they contain is already defined in a fairly compact structure, though one attribute of the RouterInfo structure is not - "options" is a plain ASCII name = value mapping. Right now, we're filling it with those published statistics - around 3300 bytes per peer. Trivial to implement GZip compression would nearly cut that to 1/3 its size, and when you consider how often RouterInfo structures are passed across the network, thats significant savings - every time a router asks another router for a networkDb entry that the peer doesn't have, it sends back 3-10 RouterInfo of them.

+ +

Update the ministreaming protocol

+ +

Currently mihi's ministreaming library has a fairly simple stream negotiation protocol - Alice sends Bob a SYN message, Bob replies with an ACK message, then Alice and Bob send each other some data, until one of them sends the other a CLOSE message. For long lasting connections (to an irc server, for instance), that overhead is negligible, but for simple one-off request/response situations (an HTTP request/reply, for instance), thats more than twice as many messages as necessary. If, however, Alice piggybacked her first payload in with the SYN message, and Bob piggybacked his first reply with the ACK - and perhaps also included the CLOSE flag - transient streams such as HTTP requests could be reduced to a pair of messages, instead of the SYN+ACK+request+response+CLOSE.

+ +

Implement full streaming protocol

+ +

The ministreaming protocol takes advantage of a poor design decision in the I2P client procotol (I2CP) - the exposure of "mode=GUARANTEED", allowing what would otherwise be an unreliable, best-effort, message based protocol to be used for reliable, blocking operation (under the covers, its still all unreliable and message based, with the router providing delivery guarantees by garlic wrapping an "ack" message in with the payload, so once the data gets to the target, the ack message is forwarded back to us [through tunnels, of course]).

+ +

As I've said, having I2PTunnel (and the ministreaming lib) go this route was the best thing that could be done, but more efficient mechanisms are available. When we rip out the "mode=GUARANTEED" functionality, we're essentially leaving ourselves with an I2CP that looks like an anonymous IP layer, and as such, we'll be able to implement the streaming library to take advantage of the design experiences of the TCP layer - selective ACKs, congestion detection, nagle, etc.

diff --git a/pages/roadmap.html b/pages/roadmap.html new file mode 100644 index 00000000..655f6a64 --- /dev/null +++ b/pages/roadmap.html @@ -0,0 +1,65 @@ +

Roadmap

+ +

0.3.2 (May)

Fixed the netDb for more reliability
Address the diversification issues in peer selection
Fix remaining "unknown tunnels" cause

+ +

0.3.3 (July)

Unique tunnelIDs per hop to increase anonymity
Remove SourceRouteReplyMessage, replace SourceRouteBlock with ReplyBlock (no encrypted data in it, just a sessionTag + sessionKey)
Out of the 0.3.* testnet - irc, eepsites, and squid should work reliably

+ +

0.4.0 (July)

Updated deployment architecture, replacing the admin console with a real web server and + allowing the integration of standard .war packages as client applications
New installer and web based config system
SAM bridge and client libraries implemented and tested

+ +

0.4.1 (July)

AMOC transport to allow people behind firewalls/etc to fully participate in I2P
Bandwidth limiter functional
Router throttling code (detect/adapt to overload by refusing tunnels, shrinking # connections, minimizing networkDb activity)

+ +

1.0 (August)

Javadoc and code walkthrough / guidebook updated
Comprehensive management tool available
Internal code audit complete
MyI2P available

+ +

1.1 (September)

Full streaming protocol implemented

+ +

2.0 (October)

Restricted route topology (include some connected peers in routerInfo, recursive route)
Connectionless/alternate transports (UDP, MRTCP, SMTP+POP3/IMAP)
Nontrivial certificates (hashcash, other)

+ +

3.0 (December)

Sender defined message delays
Creator defined tunnel mixing and pooling of messages, as well as optional chaff messages
(Mixminion integration?)

+ +Dates, of course, are just estimates. If you get involved and help out with some of the +coding, things will go faster diff --git a/pages/team.html b/pages/team.html new file mode 100644 index 00000000..e78936b4 --- /dev/null +++ b/pages/team.html @@ -0,0 +1,189 @@ +

I2P Team

+ We are a small group of people spread around several continents, working + to advance different aspects of the project and discussing the design of + the network. +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

Admin	Project Manager	jrandom	point of contact of last resort
	Treasurer	wilde	manage donations / accounts / bounties
	Operations Manager	duck	monitor network health
	User Advocate	protocol	gather, prioritize, advocate for user needs

Dev	Core Lead	jrandom	lead dev for the SDK and router
	I2PTunnel Lead	mihi	lead dev for the I2PTunnel apps
	Integration Lead	human	lead dev for integration with other apps and networks
	Contributor	thecrypto	encryption and signature routines, I2PIM
		eco	i2psnark - bittorrent over I2P
		shendaras	general help
		aum	i2pmgr - installation and management console
		FillaMent	i2pmole - I2PTunnel management console
		MrEcho	naming service
		wiht	naming service
		ughabugha	helping with c tuning
		[vacant]	Help needed on many fronts!

QA	QA Lead	[vacant]	develop test plans, manage bugs, coordinate contributors
	QA Dev	[vacant]	automate unit and functional tests
	QA Contributor	baffled	router stress testing, bug reporting
		ughabugha	router stress testing, bug reporting
		JAnonymous	router stress testing, bug reporting
		jar	router stress testing, bug reporting
		Masterboy	router stress testing, bug reporting
		[vacant]	router stress testing, bug reporting

Web	Webmaster	wilde	manage web issues re: hosting, programming, etc
	Web Editor	[vacant]	coordinate docs: whats needed, how its organized, who is working on what
	Web Designer	[anon]	[working on graphics, stylesheets, layout]
	Web Author	JAnonymous	getting started docs, wiki migration
		ughabugha	wiki migration, doc cleanup
		duck	howtos
		jrandom	overview docs, tech docs
		jar	translations into French
		[vacant]	help with intro docs, walkthroughs, howtos, and explanatory materials needed!

+ +

+ We are very open to other developers who want to get involved and anyone else who would like to contribute in other ways, such as critiques, peer review, testing, writing I2P enabled applications, or documentation. Almost everything is written in Java (1.3+), though some third party applications are being written in Python. The code generally works on Kaffe, and GCJ support is slated for the 1.1 release. + +

diff --git a/styles/default.css b/styles/default.css new file mode 100644 index 00000000..baaf8156 --- /dev/null +++ b/styles/default.css @@ -0,0 +1,51 @@ +body { + font-family: Verdana, Tahoma, Helvetica, sans-serif; + margin: 1em 0em; + padding: 0em; + text-align:center; + background-color: white; + color: black; +} + +div.logo { + float: left; + left: 1em; + top: 1em; + margin: 0em; + padding: .5em; + text-align: left; +} + +div.menu { + /* width: 8em; */ + /* height: 5em; */ + /* position: fixed; */ + float: left; + left: 1em; + top: 1em; + margin: 0em; + padding: .5em; + text-align: left; + border: medium solid #efefff; + background-color: #fafaff; + color: inherit; + font-size: small; +} + +div.warning { + margin: 0em 1em 1em 12em; + padding: .5em 1em; + background-color: #ffefef; + border: medium solid #ffafaf; + text-align: left; + color: inherit; +} + +div.main { + margin: 0em 1em 1em 12em; + padding: .5em 1em; + background-color: #ffffef; + border: medium solid #ffffd0; + text-align: left; + color: inherit; +}

Name	Status	Judge	Dev ^*	Bounty
MyI2P	Proposal in development	jrandom	None yet	$110
Streaming library window size	Proposal in development	[vacant]	None yet	$60
Swarming file transfer	Proposal in development	[vacant]	None yet
Distributed data store	Proposal in development	[vacant]	Nightblade
IRC connect time monitor	CLAIMED for $10 USD	jrandom	hypercubus
Native GMP packaging	Proposal in development	jrandom	None yet

E-gold	Paypal
1.979 g (~24.02 USD)	98.53 USD

Amount:
Units:	of e-gold
Memo:
	(enter the bounty name that this donation is for, + +also if you want credit add your nym)

Applications

Application development guide

Why write I2P specific code?

Important ideas

Destination ~= host+port

Anonymity and confidentiality

I2P datagrams can be up to 32KB

Integration techniques

SAM

I2PTunnel

ministreaming and datagrams

I2CP

Bounties

Current bounties

General fund balance

CVS

Donate

e-gold

PayPal

FAQ

What is I2P?

What does that mean?

What is the difference between I2P and the internet?

Whats an "eepsite"?

Can I browse the web with I2P?

How anonymous is I2P anyway?

How does I2P protect itself from denial of service attacks?

I have a question!

Hall of Fame

I2P

Welcome on I2P.net

ElGamal / AES+SessionTag

Intro

Why?

How?

When?

Who?

Where?

Threatmodel

Morphmix and Tarzan

TOR / Onion Routing

Mixminion / Mixmaster

Freenet

JAP

jbigi

Requirements

Step-by-step instructions

Licenses

All software bundled in the I2P distributions will allow:

Component licenses

GPL + java exception

CVS commit priviliges

MinWWW

Performance

Native math

Garlic wrapping a "reply" LeaseSet

Better peer profiling and selection

Network database tuning

Longer SessionTag lifetime

Longer lasting tunnels

Adjust the timeouts

More efficient TCP rejection

Adjust the tunnel testing

Compress some data structures

Update the ministreaming protocol

Implement full streaming protocol

Roadmap

0.3.2 (May)

0.3.3 (July)

0.4.0 (July)

0.4.1 (July)

1.0 (August)

1.1 (September)

2.0 (October)

3.0 (December)

I2P Team