merge of '2f2711c1ae07a6fdd51c8ddd5675c2b19ce0d094'
and 'dce34975852d12e429f92fd82e7f17c8143047c5'
This commit is contained in:
210
i2p2www/blog/2019/05/25/help-bootstrap-bote.rst
Normal file
210
i2p2www/blog/2019/05/25/help-bootstrap-bote.rst
Normal file
@ -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 %}
|
@ -1,7 +1,7 @@
|
|||||||
{% extends "global/layout.html" %}
|
{% extends "global/layout.html" %}
|
||||||
{% block title %}I2CP{% endblock %}
|
{% block title %}I2CP{% endblock %}
|
||||||
{% block lastupdated %}{% trans %}March 2019{% endtrans %}{% endblock %}
|
{% block lastupdated %}{% trans %}May 2019{% endtrans %}{% endblock %}
|
||||||
{% block accuratefor %}0.9.39{% endblock %}
|
{% block accuratefor %}0.9.41{% endblock %}
|
||||||
{% block content %}
|
{% block content %}
|
||||||
<p>{% trans -%}
|
<p>{% trans -%}
|
||||||
The I2P Client Protocol (I2CP) exposes a strong separation of concerns between
|
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>
|
<tr>
|
||||||
<td>i2cp.leaseSetAuthType
|
<td>i2cp.leaseSetAuthType
|
||||||
<td>0.9.39</td>
|
<td>0.9.41</td>
|
||||||
<td>0
|
<td>0
|
||||||
<td>0-2
|
<td>0-2
|
||||||
<td>0
|
<td>0
|
||||||
@ -232,14 +232,17 @@ See proposal 123.
|
|||||||
|
|
||||||
<tr>
|
<tr>
|
||||||
<td>i2cp.leaseSetPrivKey
|
<td>i2cp.leaseSetPrivKey
|
||||||
<td>0.9.39</td>
|
<td>0.9.41</td>
|
||||||
<td>
|
<td>
|
||||||
<td>
|
<td>
|
||||||
<td>
|
<td>
|
||||||
<td>
|
<td>
|
||||||
A base 64 private key for the router to use to decrypt the encrypted leaseset,
|
A base 64 X25519 private key for the router to use to decrypt the encrypted LS2 locally,
|
||||||
only if per-client authentication is enabled
|
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.
|
See proposal 123.
|
||||||
|
Do not confuse with i2cp.leaseSetPrivateKey which is for LS1.
|
||||||
</td>
|
</td>
|
||||||
</tr>
|
</tr>
|
||||||
|
|
||||||
@ -661,7 +664,7 @@ See proposal 123.
|
|||||||
|
|
||||||
<tr>
|
<tr>
|
||||||
<td>i2cp.leaseSetAuthType
|
<td>i2cp.leaseSetAuthType
|
||||||
<td>0.9.39</td>
|
<td>0.9.41</td>
|
||||||
<td>0
|
<td>0
|
||||||
<td>0-2
|
<td>0-2
|
||||||
<td>0
|
<td>0
|
||||||
@ -706,12 +709,13 @@ See proposals 123, 144, and 145.
|
|||||||
<td>
|
<td>
|
||||||
<td>
|
<td>
|
||||||
<td>{% trans -%}
|
<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 ':'.
|
Optionally preceded by the key type and ':'.
|
||||||
Only "ELGAMAL_2048:" is supported, which is the default.
|
Only "ELGAMAL_2048:" is supported, which is the default.
|
||||||
I2CP will generate the public key from the private key.
|
I2CP will generate the public key from the private key.
|
||||||
Use for persistent leaseset keys across restarts.
|
Use for persistent leaseset keys across restarts.
|
||||||
{%- endtrans %}</td>
|
{%- endtrans %}</td>
|
||||||
|
Do not confuse with i2cp.leaseSetPrivKey which is for LS2.
|
||||||
</tr>
|
</tr>
|
||||||
|
|
||||||
<tr>
|
<tr>
|
||||||
|
@ -4,7 +4,7 @@ Encrypted LeaseSet Specification
|
|||||||
.. meta::
|
.. meta::
|
||||||
:category: Protocols
|
:category: Protocols
|
||||||
:lastupdated: May 2019
|
:lastupdated: May 2019
|
||||||
:accuratefor: 0.9.40
|
:accuratefor: 0.9.41
|
||||||
|
|
||||||
.. contents::
|
.. contents::
|
||||||
|
|
||||||
@ -675,6 +675,7 @@ authCookie = DECRYPT(clientKey_i, clientIV_i, clientCookie_i)
|
|||||||
Pre-shared key client authorization
|
Pre-shared key client authorization
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
Each client generates a secret 32-byte key ``psk_i``, and sends it to the server.
|
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
|
Server processing
|
||||||
^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^
|
||||||
@ -753,10 +754,13 @@ Downsides of DH client authorization
|
|||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
- Requires N + 1 DH operations on the server side for N clients.
|
- Requires N + 1 DH operations on the server side for N clients.
|
||||||
- Requires one DH operation on the client side.
|
- Requires one DH operation on the client side.
|
||||||
|
- Requires the client to generate the secret key.
|
||||||
|
|
||||||
Advantages of PSK client authorization
|
Advantages of PSK client authorization
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
- Requires no DH operations.
|
- 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
|
Downsides of PSK client authorization
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
@ -3,8 +3,8 @@ I2CP Specification
|
|||||||
==================
|
==================
|
||||||
.. meta::
|
.. meta::
|
||||||
:category: Protocols
|
:category: Protocols
|
||||||
:lastupdated: March 2019
|
:lastupdated: May 2019
|
||||||
:accuratefor: 0.9.39
|
:accuratefor: 0.9.41
|
||||||
|
|
||||||
.. contents::
|
.. contents::
|
||||||
|
|
||||||
@ -532,7 +532,10 @@ RequestVariableLeaseSetMessage_ and contains all of the [Lease]_ structures that
|
|||||||
should be published to the I2NP Network Database.
|
should be published to the I2NP Network Database.
|
||||||
|
|
||||||
Sent from Client to Router.
|
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
|
Contents
|
||||||
````````
|
````````
|
||||||
|
@ -5,7 +5,7 @@ New netDB Entries
|
|||||||
:author: zzz, str4d, orignal
|
:author: zzz, str4d, orignal
|
||||||
:created: 2016-01-16
|
:created: 2016-01-16
|
||||||
:thread: http://zzz.i2p/topics/2051
|
:thread: http://zzz.i2p/topics/2051
|
||||||
:lastupdated: 2019-05-21
|
:lastupdated: 2019-05-22
|
||||||
:status: Open
|
:status: Open
|
||||||
:supercedes: 110, 120, 121, 122
|
:supercedes: 110, 120, 121, 122
|
||||||
|
|
||||||
@ -1123,6 +1123,8 @@ authCookie = DECRYPT(clientKey_i, clientIV_i, clientCookie_i)
|
|||||||
Pre-shared key client authorization
|
Pre-shared key client authorization
|
||||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
Each client generates a secret 32-byte key ``psk_i``, and sends it to the server.
|
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
|
Server processing
|
||||||
^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^
|
||||||
@ -1201,10 +1203,13 @@ Downsides of DH client authorization
|
|||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
- Requires N + 1 DH operations on the server side for N clients.
|
- Requires N + 1 DH operations on the server side for N clients.
|
||||||
- Requires one DH operation on the client side.
|
- Requires one DH operation on the client side.
|
||||||
|
- Requires the client to generate the secret key.
|
||||||
|
|
||||||
Advantages of PSK client authorization
|
Advantages of PSK client authorization
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
- Requires no DH operations.
|
- 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
|
Downsides of PSK client authorization
|
||||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||||
|
@ -37,7 +37,9 @@ L
|
|||||||
Elliptic curve's group order. Property of curve.
|
Elliptic curve's group order. Property of curve.
|
||||||
|
|
||||||
DERIVE_PUBLIC(a)
|
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.
|
A 32-byte random number known to those who know the destination.
|
||||||
|
|
||||||
GENERATE_ALPHA(destination, date, secret)
|
GENERATE_ALPHA(destination, date, secret)
|
||||||
|
@ -10,3 +10,34 @@ div#content .inner .meta {
|
|||||||
right: 2%;
|
right: 2%;
|
||||||
text-align: left;
|
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;
|
||||||
|
}}
|
||||||
|
Reference in New Issue
Block a user