diff --git a/www.i2p2/pages/faq.html b/www.i2p2/pages/faq.html index 3cf7921c..95bc968d 100644 --- a/www.i2p2/pages/faq.html +++ b/www.i2p2/pages/faq.html @@ -164,6 +164,14 @@ Two key settings are the inbound and outbund bandwidth limiters on With the default settings of 16KBps you will generally get no better than 5KBps data transfer in I2PSnark. Increasing the settings (but keeping within your actual connection limitations) will increase the potential transfer rate for I2PSnark and all other applications. +

+Also, do you have sufficient share bandwidth configured to allow participating tunnels +to route through your router? Believe it or not, allowing participating traffic +keeps you well-integrated in the network and helps your own transfer speeds. +

+I2P is a work in progress. Lots of improvements and fixes are being implemented, and +generally speaking, running the latest release will help your performance. +If you haven't, install the latest release.

Bittorrent / I2PSnark / Azureus I2P Plugin Questions? diff --git a/www.i2p2/pages/how_intro.html b/www.i2p2/pages/how_intro.html index fbf8f4c6..174fdf64 100644 --- a/www.i2p2/pages/how_intro.html +++ b/www.i2p2/pages/how_intro.html @@ -1,11 +1,11 @@ {% extends "_layout.html" %} {% block title %}Introduction to How I2P Works{% endblock %} -{% block content %}Note: these documents have not yet been updated to include the changes made -in I2P 0.5 - the new +{% block content %}Note: the "how" documents have not been fully updated to include several changes +including the new tunnel routing and encryption algorithms, addressing several issues (with the groundwork for addressing -others). +others), and other changes.

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, @@ -91,11 +91,13 @@ a full laundry list includes 2048bit ElGamal encryption, 256bit AES in CBC mode 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 +

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 (I2CP) encryption was disabled in I2P release 0.6; end-to-end (garlic) encryption +remains. Disregard the "Alice-to-Bob" encryption in the picture below.

end to end layered encryption

diff --git a/www.i2p2/pages/i2cp.html b/www.i2p2/pages/i2cp.html index a9e4021d..a61630b9 100644 --- a/www.i2p2/pages/i2cp.html +++ b/www.i2p2/pages/i2cp.html @@ -22,6 +22,12 @@ Instead, applications can take advantage of the base I2CP plus the by using the Simple Anonymous Messaging protocol (which does not require clients to deal with any sort of cryptography).

+

Actually, I2CP end-to-end encryption was disabled in I2P release 0.6, +leaving in place the end-to-end garlic encryption. +However, client libraries must still implement public/private key signing +for leasesets, and key management. +

+

While the I2CP has been quite stable since its inception in August of 2003, there have been minor modifications on occasion. Here is the diff --git a/www.i2p2/pages/i2np.html b/www.i2p2/pages/i2np.html index 59682cd3..831f0c05 100644 --- a/www.i2p2/pages/i2np.html +++ b/www.i2p2/pages/i2np.html @@ -41,6 +41,10 @@ These are globabl queues for all peers. NTCP has a trivial linear search for the highest priority within each buffer for a particular peer. This is much less effective. +

+It isn't clear whether the current priority scheme is generally effective, +and whether the priorities for various messages should be adjusted further. +This is a topic for further research, analysis and testing.

Message Format

@@ -87,14 +91,20 @@ DatabaseLookupMessage DatabaseSearchReplyMessage 3 -  +Typ. 161 300 +Size is 65 + 32*(number of hashes) where typically, the hashes for +three floodfill routers are returned. DatabaseStoreMessage 1 -  +Varies 100/400 Usually 100 (why?) +Size is 898 bytes for a typical 2-lease leaseSet. +RouterInfo structures are compressed, and size varies; however +there is a continuing effort to reduce the amount of data published in a RouterInfo +as we appproach release 1.0. DataMessage 20 @@ -105,7 +115,7 @@ DateMessage 16     -Obsolete (was used by TCP), date messages now at the I2CP layer ? +Obsolete (was used by TCP), date messages now at the I2CP layer ? DeliveryStatusMessage 10