|
|
|
|
@ -1,7 +1,7 @@
|
|
|
|
|
{% extends "global/layout.html" %}
|
|
|
|
|
{% block title %}{% trans %}Naming and Addressbook{% endtrans %}{% endblock %}
|
|
|
|
|
{% block lastupdated %}{% trans %}June 2018{% endtrans %}{% endblock %}
|
|
|
|
|
{% block accuratefor %}0.9.34{% endblock %}
|
|
|
|
|
{% block lastupdated %}{% trans %}June 2019{% endtrans %}{% endblock %}
|
|
|
|
|
{% block accuratefor %}0.9.41{% endblock %}
|
|
|
|
|
{% block content %}
|
|
|
|
|
<h2 id="overview">{% trans %}Overview{% endtrans %}</h2>
|
|
|
|
|
|
|
|
|
|
@ -469,7 +469,7 @@ Example: <code>ukeu3k5oycgaauneqgtnvselmt4yemvoilkln7jpvamvfx7dnkdq.b32.i2p</cod
|
|
|
|
|
In Tor, the address is 16 characters (80 bits), or half of the SHA-1 hash.
|
|
|
|
|
I2P uses 52 characters (256 bits) to represent the full SHA-256 hash.
|
|
|
|
|
The form is {52 chars}.b32.i2p.
|
|
|
|
|
Tor has recently published a
|
|
|
|
|
Tor has a
|
|
|
|
|
<a href="https://blog.torproject.org/blog/tor-weekly-news-%E2%80%94-december-4th-2013">proposal</a>
|
|
|
|
|
to convert to an identical format of {52 chars}.onion for their hidden services.
|
|
|
|
|
Base32 is implemented in the naming service, which queries the
|
|
|
|
|
@ -487,3 +487,137 @@ name does not immediately resolve. I2PTunnel will fail, for example, if
|
|
|
|
|
the name does not resolve to a destination.
|
|
|
|
|
{%- endtrans %}</p>
|
|
|
|
|
{% endblock %}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h2 id="newbase32">Extended Base32 Names</h2>
|
|
|
|
|
<p>
|
|
|
|
|
Extended base 32 names were introduced in release 0.9.40
|
|
|
|
|
to support encrypted lease sets.
|
|
|
|
|
Addresses for encrypted leasesets are identified by 56 or more encoded characters,
|
|
|
|
|
not including the ".b32.i2p"
|
|
|
|
|
(35 or more decoded bytes), compared to 52 characters (32 bytes) for traditional base 32 addresses.
|
|
|
|
|
See proposals 123 and 149 for additional information.
|
|
|
|
|
</p><p>
|
|
|
|
|
Standard Base 32 ("b32") addresses contain the hash of the destination.
|
|
|
|
|
This will not work for encrypted ls2 (proposal 123).
|
|
|
|
|
</p><p>
|
|
|
|
|
You can't use a traditional base 32 address for an encrypted LS2 (proposal 123),
|
|
|
|
|
as it contains only the hash of the destination. It does not provide the non-blinded public key.
|
|
|
|
|
Clients must know the destination's public key, sig type,
|
|
|
|
|
the blinded sig type, and an optional secret or private key
|
|
|
|
|
to fetch and decrypt the leaseset.
|
|
|
|
|
Therefore, a base 32 address alone is insufficient.
|
|
|
|
|
The client needs either the full destination (which contains the public key),
|
|
|
|
|
or the public key by itself.
|
|
|
|
|
If the client has the full destination in an address book, and the address book
|
|
|
|
|
supports reverse lookup by hash, then the public key may be retrieved.
|
|
|
|
|
</p><p>
|
|
|
|
|
So we need a new format that puts the public key instead of the hash into
|
|
|
|
|
a base32 address. This format must also contain the signature type of the
|
|
|
|
|
public key, and the signature type of the blinding scheme.
|
|
|
|
|
</p><p>
|
|
|
|
|
This section documents a new b32 format for these addresses.
|
|
|
|
|
While we have referred to this new format during discussions
|
|
|
|
|
as a "b33" address, the actual new format retains the usual ".b32.i2p" suffix.
|
|
|
|
|
</p><p>
|
|
|
|
|
|
|
|
|
|
<h3>Creation and encoding</h3>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Construct a hostname of {56+ chars}.b32.i2p (35+ chars in binary) as follows.
|
|
|
|
|
First, construct the binary data to be base 32 encoded:
|
|
|
|
|
</p>
|
|
|
|
|
<pre>
|
|
|
|
|
flag (1 byte)
|
|
|
|
|
bit 0: 0 for one-byte sigtypes, 1 for two-byte sigtypes
|
|
|
|
|
bit 1: 0 for no secret, 1 if secret is required
|
|
|
|
|
bit 2: 0 for no per-client auth,
|
|
|
|
|
1 if client private key is required
|
|
|
|
|
bits 7-3: Unused, set to 0
|
|
|
|
|
|
|
|
|
|
public key sigtype (1 or 2 bytes as indicated in flags)
|
|
|
|
|
If 1 byte, the upper byte is assumed zero
|
|
|
|
|
|
|
|
|
|
blinded key sigtype (1 or 2 bytes as indicated in flags)
|
|
|
|
|
If 1 byte, the upper byte is assumed zero
|
|
|
|
|
|
|
|
|
|
public key
|
|
|
|
|
Number of bytes as implied by sigtype
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
<p>
|
|
|
|
|
Post-processing and checksum:
|
|
|
|
|
</p>
|
|
|
|
|
<pre>
|
|
|
|
|
Construct the binary data as above.
|
|
|
|
|
Treat checksum as little-endian.
|
|
|
|
|
Calculate checksum = CRC-32(data[3:end])
|
|
|
|
|
data[0] ^= (byte) checksum
|
|
|
|
|
data[1] ^= (byte) (checksum >> 8)
|
|
|
|
|
data[2] ^= (byte) (checksum >> 16)
|
|
|
|
|
|
|
|
|
|
hostname = Base32.encode(data) || ".b32.i2p"
|
|
|
|
|
</pre>
|
|
|
|
|
<p>
|
|
|
|
|
Any unused bits at the end of the b32 must be 0.
|
|
|
|
|
There are no unused bits for a standard 56 character (35 byte) address.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<h3>Decoding and Verification</h3>
|
|
|
|
|
<pre>
|
|
|
|
|
Strip the ".b32.i2p" from the hostname
|
|
|
|
|
data = Base32.decode(hostname)
|
|
|
|
|
Calculate checksum = CRC-32(data[3:end])
|
|
|
|
|
Treat checksum as little-endian.
|
|
|
|
|
flags = data[0] ^ (byte) checksum
|
|
|
|
|
if 1 byte sigtypes:
|
|
|
|
|
pubkey sigtype = data[1] ^ (byte) (checksum >> 8)
|
|
|
|
|
blinded sigtype = data[2] ^ (byte) (checksum >> 16)
|
|
|
|
|
else (2 byte sigtypes) :
|
|
|
|
|
pubkey sigtype = data[1] ^ ((byte) (checksum >> 8)) || data[2] ^ ((byte) (checksum >> 16))
|
|
|
|
|
blinded sigtype = data[3] || data[4]
|
|
|
|
|
parse the remainder based on the flags to get the public key
|
|
|
|
|
</pre>
|
|
|
|
|
|
|
|
|
|
<h3>Secret and Private Key Bits</h3>
|
|
|
|
|
<p>
|
|
|
|
|
The secret and private key bits are used to indicate to clients, proxies, or other
|
|
|
|
|
client-side code that the secret and/or private key will be required to decrypt the
|
|
|
|
|
leaseset. Particular implementations may prompt the user to supply the
|
|
|
|
|
required data, or reject connection attempts if the required data is missing.
|
|
|
|
|
</p>
|
|
|
|
|
|
|
|
|
|
<h3>Notes</h3>
|
|
|
|
|
|
|
|
|
|
<ul><li>
|
|
|
|
|
XORing first 3 bytes with the hash provides a limited checksum capability,
|
|
|
|
|
and ensures that all base32 chars at the beginning are randomized.
|
|
|
|
|
Only a few flag and sigtype combinations are valid, so any typo is likely to create an invalid combination and will be rejected.
|
|
|
|
|
</li><li>
|
|
|
|
|
In the usual case (1 byte sigtypes, no secret, no per-client auth),
|
|
|
|
|
the hostname will be {56 chars}.b32.i2p, decoding to 35 bytes, same as Tor.
|
|
|
|
|
</li><li>
|
|
|
|
|
Tor 2-byte checksum has a 1/64K false negative rate. With 3 bytes, minus a few ignored bytes,
|
|
|
|
|
ours is approaching 1 in a million, since most flag/sigtype combinations are invalid.
|
|
|
|
|
</li><li>
|
|
|
|
|
Adler-32 is a poor choice for small inputs, and for detecting small changes.
|
|
|
|
|
We use CRC-32 instead. CRC-32 is fast and is widely available.
|
|
|
|
|
</li><li>
|
|
|
|
|
While outside the scope of this specification, routers and/or clients must remember and cache
|
|
|
|
|
(probably persistently) the mapping of public key to destination, and vice versa.
|
|
|
|
|
</li><li>
|
|
|
|
|
Distinguish old from new flavors by length. Old b32 addresses are always {52 chars}.b32.i2p. New ones are {56+ chars}.b32.i2p
|
|
|
|
|
</li><li>
|
|
|
|
|
Tor discussion thread <a href="https://lists.torproject.org/pipermail/tor-dev/2017-January/011816.html">is here</a>
|
|
|
|
|
</li><li>
|
|
|
|
|
Don't expect 2-byte sigtypes to ever happen, we're only up to 13. No need to implement now.
|
|
|
|
|
</li><li>
|
|
|
|
|
New format can be used in jump links (and served by jump servers) if desired, just like b32.
|
|
|
|
|
</li><li>
|
|
|
|
|
Any secret, private key, or public key longer than 32 bytes would
|
|
|
|
|
exceed the DNS max label length of 63 chars. Browsers probably do not care.
|
|
|
|
|
</li><li>
|
|
|
|
|
No backward compatibility issues. Longer b32 addresses will fail to be converted
|
|
|
|
|
to 32-byte hashes in old software.
|
|
|
|
|
</li></ul>
|
|
|
|
|
|
