I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Packages Projects Releases Wiki Activity

Update roadmap

Browse Source 
Prop. 123 updates
New prop. 148
This commit is contained in:
zzz
2019-03-12 11:46:18 +00:00
parent 305101743d
commit 964ec4fc5f
6 changed files with 414 additions and 78 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
i2p2www/pages/site/get-involved/roadmap.html
View File

@@ -1,6 +1,6 @@
{% extends "global/layout.html" %}
{% block title %}{{ _('Roadmap') }}{% endblock %}
{% block lastupdated %}{% trans %}February 2019{% endtrans %}{% endblock %}
{% block lastupdated %}{% trans %}March 2019{% endtrans %}{% endblock %}
{% block content %}
<p>
@@ -315,8 +315,8 @@ Android i2ptunnel SSL crash fix
<h2 id="2019">2019 Vision</h2>
<p>
I2P connects & empowers people & communities to reclaim control over their privacy and security.
The project is a platform for communication & information sharing.
I2P connects &amp; empowers people &amp; communities to reclaim control over their privacy and security.
The project is a platform for communication &amp; information sharing.
It enables individuals to grow in communities with a censorship-resistant environment,
a space to connect and communicate.
</p>
@@ -359,34 +359,24 @@ Continue work on ECIES-X25519 support (proposal #144)
<ul><li>
Redesigned website home page
</li><li>
Tooltips for tunnnel status (ticket #1140)
</li><li>
Reduce themes (ticket #2272)
</li><li>
convert console PNGs to SVGs (ticket #2392)
</li><li>
Remove shutdown icon from reload button (ticket #2302)
</li><li>
New color palette, icons, and fonts
</li><li>
Continue work on testnet
</li><li>
Full meta LS2 support (proposal #123)
</li><li>
Full encrypted LS2 support (proposal #123)
Floodfill and client encrypted LS2 support (proposal #123)
</li><li>
LS2 client-side support (proposal #123)
</li><li>
Continue work on ECIES-X25519 support (proposal #144)
</li><li>
Add option to disable NTCP1
</li><li>
Bundle i2pcontrol
</li><li>
i2psnark UI performance
</li><li>
AppArmor fixes
</li><li>
Better support / encourage translation efforts
</li><li>
geti2p/i2p docker image available at our download page
</li><li>
starting investigation of zerodeps jre
@@ -395,17 +385,11 @@ starting investigation of monolithic installer
</li><li>
Browser identity management UI WebExtension for i2p Browser build
</li><li>
Browser tunnel identity management UI WebExtension for i2p Browser build
</li><li>
Browser news/documentation inclusion WebExtension for i2p Browser build
</li><li>
Extended SOCKS Proxy with WebExtension Native Messaging features for i2p Browser build and general use
</li><li>
Have apt-transport-i2p and all of its dependencies on-track for inclusion in Debian
(sam3 and gosam, the Go i2p application libraries), include in PPA/Project repo
</li><li>
Create .deb package for Extended SOCKS proxy for PPA/Project Repo
</li><li>
Write beginner application development guides for SAM applications
</li><li>
Start community PPA and application development (sub)forums
@@ -436,14 +420,28 @@ Feature for running devbuilds with OSX Launcher
<ul><li>
Redesigned website navigation menu
</li><li>
Remove shutdown icon from reload button (ticket #2302)
</li><li>
Refactor CSS in console to point to consolidated icons
</li><li>
Continue work on testnet
</li><li>
I2CP and router support for decrypting LS2 (proposal #123)
</li><li>
Router decryption of LS2 support (proposal #123)
</li><li>
Router-side meta LS2 support (proposal #123)
</li><li>
Continue work on ECIES-X25519 support (proposal #144)
</li><li>
Start work on Network ID detection (proposal #147)
</li><li>
Start work on BLAKE2b sig types (proposal #148)
</li><li>
GMP 6.1.2 (ticket #1869), possibly partial?
</li><li>
i2psnark UI performance
</li><li>
Debian packaging changes and improvements
</li><li>
Ready indication for Tails
@@ -456,13 +454,23 @@ Self-installing client/service demos for nginx(server only), ssh/sshd, and Matte
</li><li>
Port any maintainable, i2p-native bittorrent client to be apt-get installable in Debian, likely BiglyBT or XD
</li><li>
Produce iso for "I2P Linux Distro Redux" Project using these features
Produce ISO for "I2P Linux Distro Redux" Project using these features
</li><li>
Achieve reproducible build (#2279)
</li><li>
Add v3 onion support to Orchid, then I2P Orchid plugin
</li><li>
Fix I2P-bote?
</li><li>
Fix signing for Windows installer (launch4j/IzPack)
</li><li>
Browser tunnel identity management UI WebExtension for i2p Browser build
</li><li>
Extended SOCKS Proxy with WebExtension Native Messaging features for i2p Browser build and general use
</li><li>
Create .deb package for Extended SOCKS proxy for PPA/Project Repo
</li><li>
Better support / encourage translation efforts
</li></ul>
@@ -471,6 +479,16 @@ Fix I2P-bote?
<ul><li>
Continue work on testnet
</li><li>
Disable NTCP1
</li><li>
Per-client auth support for encrypted LS2 (proposal #123)
</li><li>
Backend for meta LS2 support (proposal #123)
</li><li>
Continue work on ECIES-X25519 support (proposal #144)
</li><li>
Begin work on SSU2?
</li><li>
Create proposal and research multipath and path-awareness via I2CP
</li><li>
I2PTunnel socket-side NIO

4
i2p2www/spec/configuration.rst
View File

@@ -2,8 +2,8 @@
Configuration File Specification
================================
.. meta::
:lastupdated: January 2018
:accuratefor: 0.9.33
:lastupdated: March 2019
:accuratefor: 0.9.39
.. contents::

34
i2p2www/spec/cryptography.rst
View File

@@ -3,8 +3,8 @@ Low-level Cryptography Specification
====================================
.. meta::
:category: Design
:lastupdated: June 2018
:accuratefor: 0.9.36
:lastupdated: March 2019
:accuratefor: 0.9.39
.. contents::
@@ -320,16 +320,26 @@ support for Router Identities was added in release 0.9.16. Support for
migrating existing Destinations from old to new signatures will be added in a
future release. Signature type is encoded in the Destination and Router
Identity, so that new signature algorithms or curves may be added at any time.
The current supported signature types are as follows:
* DSA-SHA1
* ECDSA-SHA256-P256
* ECDSA-SHA384-P384
* ECDSA-SHA512-P521
* EdDSA-SHA512-Ed25519 (as of release 0.9.15)
* RedDSA-SHA512-Ed25519 (as of release 0.9.39)
Additional signature types are used at the application layer only,
primarily for signing and verifying su3 files.
These signature types are as follows:
* RSA-SHA256-2048
* RSA-SHA384-3072
* RSA-SHA512-4096
* EdDSA-SHA512-Ed25519 (as of release 0.9.15)
* EdDSA-SHA512-Ed25519ph (as of release 0.9.25)
ECDSA
-----
@@ -338,7 +348,7 @@ ECDSA uses the standard NIST curves and standard SHA-2 hashes.
We will migrate new destinations to ECDSA-SHA256-P256 in the 0.9.16 - 0.9.19
release time frame. Usage for Router Identities is supported as of release
0.9.16 and migration may occur in early 2015.
0.9.16 and migration of existing routers happened in 2015.
RSA
---
@@ -358,7 +368,18 @@ Standard EdDSA using curve 25519 and standard 512-bit SHA-2 hashes.
Supported as of release 0.9.15.
Migration for Destinations and Router Identities is scheduled for mid-2015.
Destinations and Router Identities were migrated in late 2015.
RedDSA 25519
--=---------
Standard EdDSA using curve 25519 and standard 512-bit SHA-2 hashes,
but with different private keys, and minor modifications to signing.
For encrypted leasesets.
See [EncryptedLeaseSet]__ for details.
Supported as of release 0.9.39.
Hashes
@@ -472,6 +493,9 @@ References
Full text: http://books.google.com/books?id=cXyiNZ2_Pa0C&amp;lpg=PA173&amp;ots=PNIz3dWe4g&amp;pg=PA173#v=onepage&amp;q&amp;f=false
.. [EncryptedLeaseSet]
{{ spec_url('encryptedleaseset') }}
.. [LeaseSet]
{{ ctags_url('LeaseSet') }}

42
i2p2www/spec/encryptedleaseset.rst
View File

@@ -57,7 +57,7 @@ STREAM
SIG
The RedDSA signature scheme (corresponding to SigType 11) with key blinding.
The Red25519 signature scheme (corresponding to SigType 11) with key blinding.
It has the following functions:
DERIVE_PUBLIC(privkey)
@@ -137,7 +137,7 @@ Type
Blinded Public Key Sig Type
2 bytes, big endian
This will always be type 11, identifying a RedDSA blinded key.
This will always be type 11, identifying a Red25519 blinded key.
Blinded Public Key
Length as implied by sig type
@@ -281,7 +281,7 @@ Blinding Key Derivation
We use the following scheme for key blinding, based on Ed25519
and ZCash RedDSA [ZCASH]_.
The RedDSA signatures are over the Ed25519 curve, using SHA-512 for the hash.
The Red25519 signatures are over the Ed25519 curve, using SHA-512 for the hash.
We do not use Tor's rend-spec-v3.txt appendix A.2 [TOR-REND-SPEC-V3]_,
which has similar design goals, because its blinded public keys
@@ -292,7 +292,7 @@ Goals
~~~~~
- Signing public key in unblinded destination must be
Ed25519 (sig type 7) or RedDSA (sig type 11);
Ed25519 (sig type 7) or Red25519 (sig type 11);
no other sig types are supported
- If the signing public key is offline, the transient signing public key must also be Ed25519
- Blinding is computationally simple
@@ -310,9 +310,9 @@ Security
The security of a blinding scheme requires that the
distribution of alpha is the same as the unblinded private keys.
However, when we blind an Ed25519 private key (sig type 7)
to a RedDSA private key (sig type 11), the distribution is different.
to a Red25519 private key (sig type 11), the distribution is different.
To meet the requirements of zcash section 4.1.6.1 [ZCASH]_,
RedDSA (sig type 11) should be used for the unblinded keys as well, so that
Red25519 (sig type 11) should be used for the unblinded keys as well, so that
"the combination of a re-randomized public key and signature(s)
under that key do not reveal the key from which it was re-randomized."
We allow type 7 for existing destinations, but recommend
@@ -416,37 +416,37 @@ Both methods of calculating A' yield the same result, as required.
Signing
~~~~~~~
The unblinded leaseset is signed by the unblinded Ed25519 or RedDSA signing private key
and verified with the unblinded Ed25519 or RedDSA signing public key (sig types 7 or 11) as usual.
The unblinded leaseset is signed by the unblinded Ed25519 or Red25519 signing private key
and verified with the unblinded Ed25519 or Red25519 signing public key (sig types 7 or 11) as usual.
If the signing public key is offline,
the unblinded leaseset is signed by the unblinded transient Ed25519 or RedDSA signing private key
and verified with the unblinded Ed25519 or RedDSA transient signing public key (sig types 7 or 11) as usual.
the unblinded leaseset is signed by the unblinded transient Ed25519 or Red25519 signing private key
and verified with the unblinded Ed25519 or Red25519 transient signing public key (sig types 7 or 11) as usual.
See below for additional notes on offline keys for encrytped leasesets.
For signing of the encrypted leaseset, we use RedDSA [ZCASH]_
For signing of the encrypted leaseset, we use Red25519 based on RedDSA [ZCASH]_
to sign and verify with blinded keys.
The RedDSA signatures are over the Ed25519 curve, using SHA-512 for the hash.
The Red25519 signatures are over the Ed25519 curve, using SHA-512 for the hash.
RedDSA is similar to standard Ed25519 except as specified below.
Red25519 is similar to standard Ed25519 except as specified below.
Sign/Verify Calculations
~~~~~~~~~~~~~~~~~~~~~~~~
The outer portion of the encrypted leaseset uses RedDSA keys and signatures.
The outer portion of the encrypted leaseset uses Red25519 keys and signatures.
RedDSA is similar to Ed25519. There are two differences:
Red25519 is similar to Ed25519. There are two differences:
RedDSA private keys are generated from random numbers and then must be reduced mod l, where l is defined above.
Red25519 private keys are generated from random numbers and then must be reduced mod l, where l is defined above.
Ed25519 private keys are generated from random numbers and then "clamped" using
bitwise masking to bytes 0 and 31. This is not done for RedDSA.
bitwise masking to bytes 0 and 31. This is not done for Red25519.
The functions GENERATE_ALPHA() and BLIND_PRIVKEY() defined above generate proper
RedDSA private keys using mod l.
Red25519 private keys using mod l.
In RedDSA, the calculation of r for signing uses additional random data,
In Red25519, the calculation of r for signing uses additional random data,
and uses the public key value rather than the hash of the private key.
Because of the random data, every RedDSA signature is different, even
Because of the random data, every Red25519 signature is different, even
when signing the same data with the same key.
@@ -778,6 +778,8 @@ a base32 address. This format must also contain the signature type of the
public key, and the signature type of the blinding scheme.
The total requirements are 32 + 2 + 2 = 36 bytes, requiring 58 characters in base 32.
.. raw:: html
{% highlight lang='text' %}
data = 32 byte pubkey || 2 byte unblinded sigtype || 2 byte blinded sigtype
address = Base32Encode(data) || ".b32.i2p"

58
i2p2www/spec/proposals/123-new-netdb-entries.rst
View File

@@ -5,7 +5,7 @@ New netDB Entries
:author: zzz, str4d, orignal
:created: 2016-01-16
:thread: http://zzz.i2p/topics/2051
:lastupdated: 2019-03-10
:lastupdated: 2019-03-12
:status: Open
:supercedes: 110, 120, 121, 122
@@ -572,7 +572,7 @@ Type
Blinded Public Key Sig Type
2 bytes, big endian
This will always be type 11, identifying a RedDSA blinded key.
This will always be type 11, identifying a Red25519 blinded key.
Blinded Public Key
Length as implied by sig type
@@ -714,9 +714,9 @@ Data
Blinding Key Derivation
```````````````````````
We use the following scheme for key blinding, based on Ed25519
and ZCash RedDSA [ZCASH]_.
The RedDSA signatures are over the Ed25519 curve, using SHA-512 for the hash.
We use the following scheme for key blinding,
based on Ed25519 and ZCash RedDSA [ZCASH]_.
The Re25519 signatures are over the Ed25519 curve, using SHA-512 for the hash.
We do not use Tor's rend-spec-v3.txt appendix A.2 [TOR-REND-SPEC-V3]_,
which has similar design goals, because its blinded public keys
@@ -727,7 +727,7 @@ Goals
~~~~~
- Signing public key in unblinded destination must be
Ed25519 (sig type 7) or RedDSA (sig type 11);
Ed25519 (sig type 7) or Red25519 (sig type 11);
no other sig types are supported
- If the signing public key is offline, the transient signing public key must also be Ed25519
- Blinding is computationally simple
@@ -745,9 +745,9 @@ Security
The security of a blinding scheme requires that the
distribution of alpha is the same as the unblinded private keys.
However, when we blind an Ed25519 private key (sig type 7)
to a RedDSA private key (sig type 11), the distribution is different.
to a Red25519 private key (sig type 11), the distribution is different.
To meet the requirements of zcash section 4.1.6.1 [ZCASH]_,
RedDSA (sig type 11) should be used for the unblinded keys as well, so that
Red25519 (sig type 11) should be used for the unblinded keys as well, so that
"the combination of a re-randomized public key and signature(s)
under that key do not reveal the key from which it was re-randomized."
We allow type 7 for existing destinations, but recommend
@@ -857,50 +857,55 @@ Both methods of calculating A' yield the same result, as required.
Signing
~~~~~~~
The unblinded leaseset is signed by the unblinded Ed25519 or RedDSA signing private key
and verified with the unblinded Ed25519 or RedDSA signing public key (sig types 7 or 11) as usual.
The unblinded leaseset is signed by the unblinded Ed25519 or Red25519 signing private key
and verified with the unblinded Ed25519 or Red25519 signing public key (sig types 7 or 11) as usual.
If the signing public key is offline,
the unblinded leaseset is signed by the unblinded transient Ed25519 or RedDSA signing private key
and verified with the unblinded Ed25519 or RedDSA transient signing public key (sig types 7 or 11) as usual.
the unblinded leaseset is signed by the unblinded transient Ed25519 or Red25519 signing private key
and verified with the unblinded Ed25519 or Red25519 transient signing public key (sig types 7 or 11) as usual.
See below for additional notes on offline keys for encrytped leasesets.
For signing of the encrypted leaseset, we use RedDSA [ZCASH]_
For signing of the encrypted leaseset, we use Red25519, based on RedDSA [ZCASH]_
to sign and verify with blinded keys.
The RedDSA signatures are over the Ed25519 curve, using SHA-512 for the hash.
The Red25519 signatures are over the Ed25519 curve, using SHA-512 for the hash.
RedDSA is similar to standard Ed25519 except as specified below.
Red25519 is identical to standard Ed25519 except as specified below.
Sign/Verify Calculations
~~~~~~~~~~~~~~~~~~~~~~~~
The outer portion of the encrypted leaseset uses RedDSA keys and signatures.
The outer portion of the encrypted leaseset uses Red25519 keys and signatures.
RedDSA is similar to Ed25519. There are two differences:
Red25519 is almost identical to Ed25519. There are two differences:
RedDSA private keys are generated from random numbers and then must be reduced mod l, where l is defined above.
Red25519 private keys are generated from random numbers and then must be reduced mod l, where l is defined above.
Ed25519 private keys are generated from random numbers and then "clamped" using
bitwise masking to bytes 0 and 31. This is not done for RedDSA.
bitwise masking to bytes 0 and 31. This is not done for Red25519.
The functions GENERATE_ALPHA() and BLIND_PRIVKEY() defined above generate proper
RedDSA private keys using mod l.
Red25519 private keys using mod l.
In RedDSA, the calculation of r for signing uses additional random data,
In Red25519, the calculation of r for signing uses additional random data,
and uses the public key value rather than the hash of the private key.
Because of the random data, every RedDSA signature is different, even
Because of the random data, every Red25519 signature is different, even
when signing the same data with the same key.
Signing:
.. raw:: html
{% highlight lang='text' %}
Signing:
T = 80 random bytes
r = H*(T || publickey || message)
(rest is the same as in Ed25519)
// rest is the same as in Ed25519
{% endhighlight %}
Verification:
Same as for Ed25519
.. raw:: html
{% highlight lang='text' %}
// same as in Ed25519
{% endhighlight %}
@@ -1579,7 +1584,8 @@ preliminary and unscheduled.
New Signature Type
------------------
Add RedDSA_SHA256_Ed25519 Type 11.
Add RedDSA_SHA512_Ed25519 Type 11.
Public key is 32 bytes; private key is 32 bytes; hash is 64 bytes; signature is 64 bytes.

286
i2p2www/spec/proposals/148-eddsa-blake2b-ed25519.rst Normal file
View File

@@ -0,0 +1,286 @@
=====================
EdDSA-BLAKE2b-Ed25519
=====================
.. meta::
:author: zzz
:created: 2019-03-12
:thread: http://zzz.i2p/topics/2689
:lastupdated: 2019-03-12
:status: Open
.. contents::
Overview
========
This proposal adds two new signature types using BLAKE2b-512 with
personalization strings and salts, to replace SHA-512.
This will eliminate three classes of possible attacks.
Motivation
==========
During discussions and design of NTCP2 (proposal 111) and LS2 (proposal 123),
we briefly considered various attacks that were possible, and how to
prevent them. Three of these attacks are Length Extension Attacks,
Reuse of Signed Data, and Dupicate Message Identification.
For both NTCP2 and LS2, we decided that
these attacks were not directly relevant to the proposals at hand,
and any solutions conflicted with the goal of minimizing new primitives.
Also, we determined that the speed of the hash functions in these protocols
was not an important factor in our decisions.
Therefore, we mostly deferred the solution to a separate proposal.
While we did add some personalization features to the LS2 specification,
we did not require any new hash functions.
Many projects, such as ZCash [ZCASH]_, are using hash functions and
signature algorithms based on newer algorithms that are not vulnerable to
the following attacks.
Length Extension Attacks
------------------------
SHA-256 and SHA-512 are vulnerable to Length Extension Attacks (LEA) [LEA]_.
This is the case when actual data is signed, not the hash of the data.
In most I2P protocols (streaming, datagrams, netdb, and others), the actual
data is signed. One exception is SU3 files, where the hash is signed.
The other exception is signed datagrams for DSA (sig type 0) only,
where the hash is signed.
For other signed datagram sig types, the data is signed.
Reuse of Signed Data
--------------------
Signed data in I2P protocols may be vulnerable to
a Reuse of Signed Data (RSD) due to lack Of domain separation.
This allows an attacker to use data received in one context
(such as a signed datagram) and present it as valid, signed data
in another context (such as streaming or network database).
While it is unlikely that the signed data from one context would be parsed
as valid data in another context, it is difficult or impossible to
analyze all situations to know for sure.
Additionally, in some context, it may be possible for an attacker to
induce a victim to sign specially-crafted data which could be valid data
in another context.
Again, it is difficult or impossible to analyze all situations to know for sure.
Duplicate Message Identification
--------------------------------
I2P protocols may be vulnerable to Duplicate Message Identification (DMI).
This may allow an attacker to identify that two signed messages have the same
content, even if these messages and their signatures are encrypted.
While it is unlikely due to the encryption methods used in I2P,
it is difficult or impossible to analyze all situations to know for sure.
By using a hash function that provides a method to add a random salt,
all signatures will be different even when signing the same data.
While Red25519 as defined in proposal 123 adds a random salt to the hash function,
this does not solve the problem for unencrypted lease sets.
Speed
-----
While not a primary motivation for this proposal,
SHA-512 is relatively slow, and faster hash functions are available.
Goals
=====
- Prevent above attacks
- Minimize use of new crypto primitives
- Use proven, standard crypto primitives
- Use standard curves
- Use faster primitives if available
Design
======
Modify the existing Ed25519 and Red25519 signature types to use BLAKE2b-512
instead of SHA-512. Add unique personalization strings for each use case.
Use the BLAKE2b salt feature for Ed25519.
Justification
=============
- BLAKE2b is not vulnerable to LEA [BLAKE2]_.
- BLAKE2b provides a standard way to add personalization strings for domain separation
- BLAKE2b provides a standard way to add a random salt to prevent DMI.
- BLAKE2b is faster than SHA-256 and SHA-512 (and MD5) on modern hardware,
according to [BLAKE2]_.
- Ed25519 is still our fastest signature type, much faster than ECDSA, at least in Java.
- Ed25519 [ED25519-REFS]_ requires a 512 bit cryptographic hash function.
It does not specify SHA-512. BLAKE2b is just as suitable for the hash function.
- BLAKE2b is widely available in libraries for many programming languages, such as Noise.
Specification
=============
Use unkeyed BLAKE2b-512 as in [BLAKE2]_ with salt and personalization.
All uses of BLAKE2b signatures will use a 16-character personalization string.
When used in EdDSA_BLAKE2b_Ed25519 signing,
when hashing the data to calculate r,
set a new BLAKE2b 16-byte random salt for each signature.
When calculating S, reset the salt to the default of all-zeros.
When used in RedDSA_BLAKE2b_Ed25519 signing,
A random salt is allowed, however it is not necessary, as the signature algorithm
adds 80 bytes of random data (see proposal 123).
When used in EdDSA_BLAKE2b_Ed25519 and RedDSA_BLAKE2b_Ed25519 verification,
do not use a random salt, use the default of all-zeros.
The salt and personalization features are not specified in [RFC-7693]_;
use those features as specified in [BLAKE2]_.
Signature Types
---------------
For EdDSA_BLAKE2b_Ed25519, replace the SHA-512 hash function
in EdDSA_SHA512_Ed25519 (signature type 7)
with BLAKE2b-512. No other changes.
For RedDSA_BLAKE2b_Ed25519, replace the SHA-512 hash function
in RedDSA_SHA512_Ed25519 (signature type 11, as defined in proposal 123)
with BLAKE2b-512. No other changes.
We do not need an replacement for
EdDSA_SHA512_Ed25519ph (signature type 8) for su3 files,
because the prehashed version of EdDSA is not vulnerable to LEA.
EdDSA_SHA512_Ed25519 (signature type 7) is not supported for su3 files.
======================= =========== ====== =====
Type Type Code Since Usage
======================= =========== ====== =====
EdDSA_BLAKE2b_Ed25519 12 TBD Router Identities and Destinations
RedDSA_BLAKE2b_Ed25519 13 TBD For Destinations and encrypted leasesets only; never used for Router Identities
======================= =========== ====== =====
Common Structure Data Lengths
-----------------------------
The following applies to both new signature types.
================================== =============
Data Type Length
================================== =============
Hash 64
Private Key 32
Public Key 32
Signature 64
================================== =============
Personalizations
----------------
To provide domain separation for the various uses of signatures,
we will use the BLAKE2b personalization feature.
The following applies to both new signature types.
All uses of BLAKE2b signatures will use a 16-character personalization string.
Any new uses must be added to the table here, with a unique personalization.
The NTCP 1 and SSU handshake uses below are for the signed data defined in the
handshake itself.
Signed RouterInfos in DatabaseStore Messages will use the NetDb Entry personalization,
just as if stored in the NetDB.
================================== ==========================
Usage 16 Byte Personalization
================================== ==========================
I2CP SessionConfig "I2CP_SessionConf"
NetDB Entries (RI, LS, LS2) "network_database"
NTCP 1 handshake "NTCP_1_handshake"
Signed Datagrams "sign_datagramI2P"
Streaming "streaming_i2psig"
SSU handshake "SSUHandshakeSign"
SU3 Files n/a, not supported
================================== ==========================
Notes
=====
Issues
======
Migration
=========
The same as with the rollout for previous signature types.
We plan to change new routers from type 7 to type 12 as the default.
We plan to eventually migrate existing routers from type 7 to type 12,
using the "rekeying" process used after type 7 was introduced.
We plan to change new destinations from type 7 to type 12 as the default.
We plan to change new encrypted destinations from type 11 to type 13 as the default.
We will support blinding from types 7, 11, 12, and 13 to type 13.
We will not support blinding 12 or 13 to type 11.
New routers could start using the new sig type by default after a few months.
New destinations could start using the new sig type by default after perhaps a year.
For the minimum router version 0.9.TBD, routers must ensure:
- Do not store (or flood) a RI or LS with the new sig types to routers less than version 0.9.TBD.
- When verifying a netdb store, do not fetch a RI or LS with the new sig types from routers less than version 0.9.TBD.
- Routers with a new sig type in their RI may not connect to routers less than version 0.9.TBD,
either with NTCP, NTCP2, or SSU.
- Streaming connections and signed datagrams won't work to routers less than version 0.9.TBD,
but there's no way to know that, so these sig types should not be used by default for some period
of months or years after 0.9.TBD is released.
References
==========
.. [BLAKE2]
https://blake2.net/blake2.pdf
.. [ED25519-REFS]
"High-speed high-security signatures" by Daniel
J. Bernstein, Niels Duif, Tanja Lange, Peter Schwabe, and
Bo-Yin Yang. http://cr.yp.to/papers.html#ed25519
.. [EDDSA-FAULTS]
https://news.ycombinator.com/item?id=15414760
.. [LEA]
https://en.wikipedia.org/wiki/Length_extension_attack
.. [RFC-7693]
https://tools.ietf.org/html/rfc7693
.. [ZCASH]
https://github.com/zcash/zips/tree/master/protocol/protocol.pdf