diff --git a/i2p2www/blog/2019/05/25/help-bootstrap-bote.rst b/i2p2www/blog/2019/05/25/help-bootstrap-bote.rst new file mode 100644 index 0000000000000000000000000000000000000000..5be9b4369551a84000628328b0af9314f970f380 --- /dev/null +++ b/i2p2www/blog/2019/05/25/help-bootstrap-bote.rst @@ -0,0 +1,210 @@ +========================================================================= +{% trans -%}How to volunteer by helping I2P-Bote bootstrap{%- endtrans %} +========================================================================= + +.. meta:: + :author: idk + :date: 2019-05-20 + :excerpt: {% trans %}Help Bootstrap I2P-Bote!{% endtrans %} + +{% trans -%} +An easy way to help people message eachother privately is to run an +I2P-Bote peer which can be used by new bote users to bootstrap their own +I2P-Bote peers. Unfortunately, until now, the process of setting up an +I2P-Bote bootstrap peer has been much more obscure than it should be. +It's actually extremely simple! +{%- endtrans %} + +{% trans -%} +:: + + What is I2P-bote? + I2P-bote is a private messaging system built on i2p, which has additional + features to make it even more difficult to discern information about the + messages that are transmitted. Because of this, it can be used to transmit + private messages securely while tolerating high latency and not relying on + a centralized relay to send messages when the sender goes offline. This is + in contrast to almost every other popular private messaging system, which + either require both parties to be online or rely on a semi-trusted service + which transmits messages on behalf of senders who go offline. + + or, ELI5: It's used similarly to e-mail, but it suffers from none of e-mail's + privacy defects. + +{%- endtrans %} + +**{%- trans %}Step One: Install I2P-Bote{%- endtrans %}** + +{%- trans %} + +I2P-Bote is an i2p plugin, and installing it is very easy. The original +instructions are available at the `bote eepSite, +bote.i2p <http://bote.i2p/install/>`__, but if you want to read them on +the clearnet, these instructions come courtesy of bote.i2p: + +{%- endtrans %} + +{%- trans %} + +1. Go to the plugin install form in your routerconsole: + http://127.0.0.1:7657/configclients#plugin +2. Paste in the URL http://bote.i2p/i2pbote.su3 +3. Click Install Plugin. +4. Once installed, click SecureMail in the routerconsole sidebar or + homepage, or go to http://127.0.0.1:7657/i2pbote/ + +{%- endtrans %} + +**{%- trans %}Step Two: Get your I2P-Bote node's base64 address{%- endtrans %}** + +{%- trans %} + +This is the part where a person might get stuck, but fear not. While a +little hard to find instructions, this is actually easy and there are +several tools and options available to you, depending on what your +circumstances are. For people who want to help run bootstrap nodes as +volunteers, the best way is to retrieve the required information from +the private key file used by the bote tunnel. + +{%- endtrans %} + +**{%- trans %}Where are the keys? {%- endtrans %}** + +{%- trans %} + +I2P-Bote stores it's destination keys in a text file which, on Debian, +is located at */var/lib/i2p/i2p-config/i2pbote/local_dest.key*. In +non-Debian systems where i2p is installed by the user, the key will be +in *$HOME/.i2p/i2pbote/local_dest.key*, and on Windows, the file will be +in *C:\\ProgramData\\i2p\\i2pbote\\local_dest.key*. + +{%- endtrans %} + +**{%- trans %}Method A: Convert the plain-text key to the base64 destination{%- endtrans %}** + +{%- trans %} + +In order to convert a plain-text key into a base64 destination, one +needs to take the key and separate only the destination part from it. In +order to do this properly, one must take the following steps: + +{%- endtrans %} + +{%- trans %} + +1. First, take the full destination and decode it from i2p's base64 + character set into binary. +2. Second, take bytes 386 and 387 and convert them to a single + Big-Endian integer. +3. Add the number you computed from the two bytes in step two to 387. This is + the length of the base64 destination. +4. Take that nummber of bytes from the front of the full destination to get + the destination as a range of bytes. +5. Convert back to a base64 representation using i2p's base64 character + set. + +{%- endtrans %} + +{%- trans %} + +A number of applications and scripts exist to perform these steps for +you. Here are some of them, but this is far from exhaustive: + +{%- endtrans %} + +{%- trans %} + +- `the i2p.scripts collection of scripts(Mostly java and + bash) <https://github.com/i2p/i2p.scripts>`__ +- `my application for converting + keys(Go) <https://github.com/eyedeekay/keyto>`__ + +{%- endtrans %} + +{%- trans %} + +These capabilities are also available in a number of I2P application +development libraries. + +{%- endtrans %} + +**{%- trans %}Shortcut:{%- endtrans %}** + +{%- trans %} + +Since the local destination of your bote node is a DSA destination, then +it's quicker to just truncate the local_dest.key file to the first 516 +bytes. To do that easily, run this command when running I2P-Bote with +I2P on Debian: + +{%- endtrans %} + +{%- trans %} +:: + + sudo -u i2psvc head -c 516 /var/lib/i2p/i2p-config/i2pbote/local_dest.key + +{%- endtrans %} + +{%- trans %} + +Or, if I2P is installed as your user: + +{%- endtrans %} + +{%- trans %} +:: + + head -c 516 ~/.i2p/i2pbote/local_dest.key + +{%- endtrans %} + +**{%- trans %}Methon B: Do a lookup {%- endtrans %}** + +{%- trans %} + +If that seems like a bit too much work, it's possible for you to look up +the base64 destination of your Bote connection by querying it's base32 +address using any of the available means for looking up a base32 +address. The base32 address of your Bote node is available on the +"Connection" page under the bote plugin application, at +`127.0.0.1:7657/i2pbote/network <http://127.0.0.1:7657/i2pbote/network>`__ + +{%- endtrans %} + +**{%- trans %}Step Three: Contact Us!{%- endtrans %}** + +{%- trans %} + +.. _update-the-built-in-peerstxt-file-with-your-new-node: + +{%- endtrans %} + +**{%- trans %}Update the built-in-peers.txt file with your new node{%- endtrans %}** + +{%- trans %} + +Now that you've got the correct destination for your I2P-Bote node, the +final step is to add yourself to the default peers list for `I2P-Bote +here <https://github.com/i2p/i2p.i2p-bote/tree/master/core/src/main/resources/i2p/bote/network>`__ +here. You can do this by forking the repository, adding yourself to the +list with your name commented out, and your 516-char destination +directly below it, like this: + +{%- endtrans %} + +{%- trans %} + +:: + + # idk + QuabT3H5ljZyd-PXCQjvDzdfCec-2yv8E9i6N71I5WHAtSEZgazQMReYNhPWakqOEj8BbpRvnarpHqbQjoT6yJ5UObKv2hA2M4XrroJmydPV9CLJUCqgCqFfpG-bkSo0gEhB-GRCUaugcAgHxddmxmAsJVRj3UeABLPHLYiakVz3CG2iBMHLJpnC6H3g8TJivtqabPYOxmZGCI-P~R-s4vwN2st1lJyKDl~u7OG6M6Y~gNbIzIYeQyNggvnANL3t6cUqS4v0Vb~t~CCtXgfhuK5SK65Rtkt2Aid3s7mrR2hDxK3SIxmAsHpnQ6MA~z0Nus-VVcNYcbHUBNpOcTeKlncXsuFj8vZL3ssnepmr2DCB25091t9B6r5~681xGEeqeIwuMHDeyoXIP0mhEcy3aEB1jcchLBRLMs6NtFKPlioxz0~Vs13VaNNP~78bTjFje5ya20ahWlO0Md~x5P5lWLIKDgaqwNdIrijtZAcILn1h18tmABYauYZQtYGyLTOXAAAA + +{%- endtrans %} + +{%- trans %} + +and submitting a pull request. That's all there is to it so help keep +i2p alive, decentralized, and reliable. + +{%- endtrans %} diff --git a/i2p2www/pages/site/docs/protocol/i2cp.html b/i2p2www/pages/site/docs/protocol/i2cp.html index 410988bc9f4af023f95d1edc224c163a72f81628..7a30d2a1706392702dd92136ecbb92c5eb2e1b8e 100644 --- a/i2p2www/pages/site/docs/protocol/i2cp.html +++ b/i2p2www/pages/site/docs/protocol/i2cp.html @@ -1,7 +1,7 @@ {% extends "global/layout.html" %} {% block title %}I2CP{% endblock %} -{% block lastupdated %}{% trans %}March 2019{% endtrans %}{% endblock %} -{% block accuratefor %}0.9.39{% endblock %} +{% block lastupdated %}{% trans %}May 2019{% endtrans %}{% endblock %} +{% block accuratefor %}0.9.41{% endblock %} {% block content %} <p>{% trans -%} The I2P Client Protocol (I2CP) exposes a strong separation of concerns between @@ -176,7 +176,7 @@ of sending a MessageStatus and awaiting a ReceiveMessageBegin. <tr> <td>i2cp.leaseSetAuthType -<td>0.9.39</td> +<td>0.9.41</td> <td>0 <td>0-2 <td>0 @@ -232,14 +232,17 @@ See proposal 123. <tr> <td>i2cp.leaseSetPrivKey -<td>0.9.39</td> +<td>0.9.41</td> <td> <td> <td> <td> -A base 64 private key for the router to use to decrypt the encrypted leaseset, -only if per-client authentication is enabled +A base 64 X25519 private key for the router to use to decrypt the encrypted LS2 locally, +only if per-client authentication is enabled. +Optionally preceded by the key type and ':'. +Only "ECIES_X25519:" is supported, which is the default. See proposal 123. +Do not confuse with i2cp.leaseSetPrivateKey which is for LS1. </td> </tr> @@ -661,7 +664,7 @@ See proposal 123. <tr> <td>i2cp.leaseSetAuthType -<td>0.9.39</td> +<td>0.9.41</td> <td>0 <td>0-2 <td>0 @@ -706,12 +709,13 @@ See proposals 123, 144, and 145. <td> <td> <td>{% trans -%} -Base 64 private key for encryption. +Base 64 private key for encryption, for old encrypted LS1. Optionally preceded by the key type and ':'. Only "ELGAMAL_2048:" is supported, which is the default. I2CP will generate the public key from the private key. Use for persistent leaseset keys across restarts. {%- endtrans %}</td> +Do not confuse with i2cp.leaseSetPrivKey which is for LS2. </tr> <tr> diff --git a/i2p2www/spec/encryptedleaseset.rst b/i2p2www/spec/encryptedleaseset.rst index 812d49187e66e18db6ccde19d7ea29e371e5637c..f2c07cfc7141391822c603dc320afc1603bd3cbf 100644 --- a/i2p2www/spec/encryptedleaseset.rst +++ b/i2p2www/spec/encryptedleaseset.rst @@ -4,7 +4,7 @@ Encrypted LeaseSet Specification .. meta:: :category: Protocols :lastupdated: May 2019 - :accuratefor: 0.9.40 + :accuratefor: 0.9.41 .. contents:: @@ -675,6 +675,7 @@ authCookie = DECRYPT(clientKey_i, clientIV_i, clientCookie_i) Pre-shared key client authorization ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Each client generates a secret 32-byte key ``psk_i``, and sends it to the server. +Alternatively, the server can generate the secret key, and send it to one or more clients. Server processing ^^^^^^^^^^^^^^^^^ @@ -753,10 +754,13 @@ Downsides of DH client authorization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - Requires N + 1 DH operations on the server side for N clients. - Requires one DH operation on the client side. +- Requires the client to generate the secret key. Advantages of PSK client authorization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - Requires no DH operations. +- Allows the server to generate the secret key. +- Allows the server to share the same key with multiple clients, if desired. Downsides of PSK client authorization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/i2p2www/spec/i2cp.rst b/i2p2www/spec/i2cp.rst index a170f79b93585d8dcf7dde8145628c8739dab996..8acfcf397bee35b1200e52c21e5e69b6c6f325ef 100644 --- a/i2p2www/spec/i2cp.rst +++ b/i2p2www/spec/i2cp.rst @@ -3,8 +3,8 @@ I2CP Specification ================== .. meta:: :category: Protocols - :lastupdated: March 2019 - :accuratefor: 0.9.39 + :lastupdated: May 2019 + :accuratefor: 0.9.41 .. contents:: @@ -532,7 +532,10 @@ RequestVariableLeaseSetMessage_ and contains all of the [Lease]_ structures that should be published to the I2NP Network Database. Sent from Client to Router. -Since release 0.9.38. See proposal 123 for more information. +Since release 0.9.39. +Per-client authentication for EncryptedLeaseSet supported as of 0.9.41. +MetaLeaseSet is not yet supported via I2CP. +See proposal 123 for more information. Contents ```````` diff --git a/i2p2www/spec/proposals/123-new-netdb-entries.rst b/i2p2www/spec/proposals/123-new-netdb-entries.rst index 81e05ca307af93b582a9753187b51f93e4dab375..585c0f3fa341b7cfca5131882897f66eac91ca54 100644 --- a/i2p2www/spec/proposals/123-new-netdb-entries.rst +++ b/i2p2www/spec/proposals/123-new-netdb-entries.rst @@ -5,7 +5,7 @@ New netDB Entries :author: zzz, str4d, orignal :created: 2016-01-16 :thread: http://zzz.i2p/topics/2051 - :lastupdated: 2019-05-21 + :lastupdated: 2019-05-22 :status: Open :supercedes: 110, 120, 121, 122 @@ -1123,6 +1123,8 @@ authCookie = DECRYPT(clientKey_i, clientIV_i, clientCookie_i) Pre-shared key client authorization ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Each client generates a secret 32-byte key ``psk_i``, and sends it to the server. +Alternatively, the server can generate the secret key, and send it to one or more clients. + Server processing ^^^^^^^^^^^^^^^^^ @@ -1201,10 +1203,13 @@ Downsides of DH client authorization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - Requires N + 1 DH operations on the server side for N clients. - Requires one DH operation on the client side. +- Requires the client to generate the secret key. Advantages of PSK client authorization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - Requires no DH operations. +- Allows the server to generate the secret key. +- Allows the server to share the same key with multiple clients, if desired. Downsides of PSK client authorization ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ diff --git a/i2p2www/spec/proposals/151-ecdsa-blinding.rst b/i2p2www/spec/proposals/151-ecdsa-blinding.rst index 053c0542174bf1f6051a552a35e60a47d56813be..db03620dd4787bb15e1871fdb22a0144c916a50f 100644 --- a/i2p2www/spec/proposals/151-ecdsa-blinding.rst +++ b/i2p2www/spec/proposals/151-ecdsa-blinding.rst @@ -37,7 +37,9 @@ L Elliptic curve's group order. Property of curve. DERIVE_PUBLIC(a) - Convert a private key to public, by multiplying B over an elliptic curve alpha + Convert a private key to public, by multiplying B over an elliptic curve + +alpha A 32-byte random number known to those who know the destination. GENERATE_ALPHA(destination, date, secret) diff --git a/i2p2www/static/styles/duck/widescreen.css b/i2p2www/static/styles/duck/widescreen.css index 38e31639987a5acb0d28691cbf7c52848bdbc1bc..eca5764ebf44fffbda08200b91780b2a5ec20e6a 100644 --- a/i2p2www/static/styles/duck/widescreen.css +++ b/i2p2www/static/styles/duck/widescreen.css @@ -10,3 +10,34 @@ div#content .inner .meta { right: 2%; text-align: left; } + +@media print { div#content .aside { + word-wrap: break-word; + display: !important; +}} + +@media print { div#content .inner .fluid { + margin-right: 3%; + display: !important; +}} + +@media print { div#content .inner .meta { + position: unset; + left: unset; + margin: unset; + right: unset; + text-align: unset; + display: block !important; +}} + +@media print { div#content .inner .sidebar { + word-wrap: break-word; + margin-right: 2%; + display: !important; +}} + +@media print { div#content .content-inner { + margin-left: 3%; + padding-right: 4em; + display: !important; +}}