Update roadmap

Prop. 123 updates
New prop. 148

i2p2www/pages/site/get-involved/roadmap.html

@@ -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.
+I2P connects &amp; empowers people &amp; communities to reclaim control over their privacy and security.
-The project is a platform for communication & information sharing.
+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)
+Floodfill and client encrypted LS2 support (proposal #123)
-</li><li>
-Full 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

i2p2www/spec/configuration.rst

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

i2p2www/spec/cryptography.rst

@@ -3,8 +3,8 @@ Low-level Cryptography Specification
 ====================================
 .. meta::
     :category: Design
-    :lastupdated: June 2018
+    :lastupdated: March 2019
-    :accuratefor: 0.9.36
+    :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&lpg=PA173&ots=PNIz3dWe4g&pg=PA173#v=onepage&q&f=false
 
+.. [EncryptedLeaseSet]
+    {{ spec_url('encryptedleaseset') }}
+
 .. [LeaseSet]
     {{ ctags_url('LeaseSet') }}
 

i2p2www/spec/encryptedleaseset.rst

@@ -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
+The unblinded leaseset is signed by the unblinded Ed25519 or Red25519 signing private key
-and verified with the unblinded Ed25519 or RedDSA signing public key (sig types 7 or 11) as usual.
+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
+the unblinded leaseset is signed by the unblinded transient Ed25519 or Red25519 signing private key
-and verified with the unblinded Ed25519 or RedDSA transient signing public key (sig types 7 or 11) as usual.
+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"

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-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
+We use the following scheme for key blinding,
-and ZCash RedDSA [ZCASH]_.
+based on Ed25519 and ZCash RedDSA [ZCASH]_.
-The RedDSA signatures are over the Ed25519 curve, using SHA-512 for the hash.
+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
+The unblinded leaseset is signed by the unblinded Ed25519 or Red25519 signing private key
-and verified with the unblinded Ed25519 or RedDSA signing public key (sig types 7 or 11) as usual.
+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
+the unblinded leaseset is signed by the unblinded transient Ed25519 or Red25519 signing private key
-and verified with the unblinded Ed25519 or RedDSA transient signing public key (sig types 7 or 11) as usual.
+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
-  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:
+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.
 
 
 

i2p2www/spec/proposals/148-eddsa-blake2b-ed25519.rst

@@ -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
+
+
+