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

prop. 144 and spec updates

Browse Source
This commit is contained in:
zzz
2020-04-26 10:59:35 +00:00
parent 60256ce598
commit 06ba4cc3b4
4 changed files with 169 additions and 114 deletions
Download Patch File Download Diff File Expand all files Collapse all files

67
i2p2www/spec/common-structures.rst
View File

@ -3,8 +3,8 @@ Common structures Specification
=============================== ===============================
.. meta:: .. meta::
:category: Design :category: Design
:lastupdated: July 2019 :lastupdated: April 2020
:accuratefor: 0.9.42 :accuratefor: 0.9.46
.. contents:: .. contents::
@ -66,7 +66,7 @@ PublicKey
Description Description
``````````` ```````````
This structure is used in ElGamal encryption, representing only the exponent, This structure is used in ElGamal or other asymmetric encryption, representing only the exponent,
not the primes, which are constant and defined in the cryptography not the primes, which are constant and defined in the cryptography
specification [ELGAMAL]_. specification [ELGAMAL]_.
Other encryption schemes are in the process of being defined, see the table below. Other encryption schemes are in the process of being defined, see the table below.
@ -74,19 +74,20 @@ Other encryption schemes are in the process of being defined, see the table belo
Contents Contents
```````` ````````
Key type and length are inferred from context or are specified in the Key Key type and length are inferred from context or are specified in the Key
Certificate of a Destination or RouterInfo, or the key type field in a LeaseSet2_. Certificate of a Destination or RouterInfo, or the fields in a LeaseSet2_ or other data structure.
The default type is ElGamal. As of release The default type is ElGamal. As of release
0.9.38, other types may be supported, depending on context. 0.9.38, other types may be supported, depending on context.
Keys are big-endian unless otherwise noted.
======= ============== ===== ===== ======= ============== ====== =====
Type Length (bytes) Since Usage Type Length (bytes) Since Usage
======= ============== ===== ===== ======= ============== ====== =====
ElGamal 256 All Router Identities and Destinations ElGamal 256 All Router Identities and Destinations
P256 64 TBD Reserved, see proposal 145 P256 64 TBD Reserved, see proposal 145
P384 96 TBD Reserved, see proposal 145 P384 96 TBD Reserved, see proposal 145
P521 132 TBD Reserved, see proposal 145 P521 132 TBD Reserved, see proposal 145
X25519 32 TBD Reserved, see proposal 144 X25519 32 0.9.38 Little-endian. See proposal 144
======= ============== ===== ===== ======= ============== ====== =====
JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/PublicKey.html JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/PublicKey.html
@ -97,7 +98,7 @@ PrivateKey
Description Description
``````````` ```````````
This structure is used in ElGamal decryption, representing only the exponent, This structure is used in ElGamal or other asymmetric decryption, representing only the exponent,
not the primes which are constant and defined in the cryptography specification not the primes which are constant and defined in the cryptography specification
[ELGAMAL]_. [ELGAMAL]_.
Other encryption schemes are in the process of being defined, see the table below. Other encryption schemes are in the process of being defined, see the table below.
@ -105,19 +106,20 @@ Other encryption schemes are in the process of being defined, see the table belo
Contents Contents
```````` ````````
Key type and length are inferred from context or are specified in the Key Key type and length are inferred from context or are specified in the Key
Certificate of a Destination or RouterInfo, or the key type field in a LeaseSet2_. Certificate of a Destination or RouterInfo, or the fields in a LeaseSet2_ or other data structure.
The default type is ElGamal. As of release The default type is ElGamal. As of release
0.9.38, other types may be supported, depending on context. 0.9.38, other types may be supported, depending on context.
Keys are big-endian unless otherwise noted.
======= ============== ===== ===== ======= ============== ====== =====
Type Length (bytes) Since Usage Type Length (bytes) Since Usage
======= ============== ===== ===== ======= ============== ====== =====
ElGamal 256 All Router Identities and Destinations ElGamal 256 All Router Identities and Destinations
P256 32 TBD Reserved, see proposal 145 P256 32 TBD Reserved, see proposal 145
P384 48 TBD Reserved, see proposal 145 P384 48 TBD Reserved, see proposal 145
P521 66 TBD Reserved, see proposal 145 P521 66 TBD Reserved, see proposal 145
X25519 32 TBD Reserved, see proposal 144 X25519 32 0.9.38 Little-endian. See proposal 144
======= ============== ===== ===== ======= ============== ====== =====
JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/PrivateKey.html JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/PrivateKey.html
@ -128,7 +130,7 @@ SessionKey
Description Description
``````````` ```````````
This structure is used for AES256 encryption and decryption. This structure is used for symmetric AES256 encryption and decryption.
Contents Contents
```````` ````````
@ -172,7 +174,7 @@ Notes
serialized by padding each element to length/2 with leading zeros if serialized by padding each element to length/2 with leading zeros if
necessary. necessary.
* All types are Big Endian, except for EdDSA, which is stored and transmitted * All types are Big Endian, except for EdDSA and RedDSA, which are stored and transmitted
in a Little Endian format. in a Little Endian format.
JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/SigningPublicKey.html JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/SigningPublicKey.html
@ -212,7 +214,7 @@ Notes
serialized by padding each element to length/2 with leading zeros if serialized by padding each element to length/2 with leading zeros if
necessary. necessary.
* All types are Big Endian, except for EdDSA, which is stored and transmitted * All types are Big Endian, except for EdDSA and RedDSA, which are stored and transmitted
in a Little Endian format. in a Little Endian format.
JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/SigningPrivateKey.html JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/SigningPrivateKey.html
@ -253,7 +255,7 @@ Notes
serialized by padding each element to length/2 with leading zeros if serialized by padding each element to length/2 with leading zeros if
necessary. necessary.
* All types are Big Endian, except for EdDSA, which is stored and transmitted * All types are Big Endian, except for EdDSA and RedDSA, which are stored and transmitted
in a Little Endian format. in a Little Endian format.
JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/Signature.html JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/Signature.html
@ -437,7 +439,7 @@ ElGamal 0 256 All Router Identities and Destin
P256 1 64 Reserved, see proposal 145 P256 1 64 Reserved, see proposal 145
P384 2 96 Reserved, see proposal 145 P384 2 96 Reserved, see proposal 145
P521 3 132 Reserved, see proposal 145 P521 3 132 Reserved, see proposal 145
X25519 4 32 Reserved, see proposal 144 X25519 4 32 Not for use in key certs. See proposal 144
reserved 65280-65534 Reserved for experimental use reserved 65280-65534 Reserved for experimental use
reserved 65535 Reserved for future expansion reserved 65535 Reserved for future expansion
======== =========== ======================= ===== ======== =========== ======================= =====
@ -1188,8 +1190,9 @@ Notes
* The encryption keys are used for end-to-end ElGamal/AES+SessionTag encryption * The encryption keys are used for end-to-end ElGamal/AES+SessionTag encryption
[ELGAMAL-AES]_ (type 0) or other end-to-end encryption schemes. [ELGAMAL-AES]_ (type 0) or other end-to-end encryption schemes.
See proposals 123, 144, and 145. See proposals 123, 144, and 145.
They are currently generated anew at every router startup They may be generated anew at every router startup
they are not persistent. or they may be persistent.
X25519 (type 4, proposal 144) is supported as of release 0.9.44.
* The signature is over the data above, PREPENDED with the single byte * The signature is over the data above, PREPENDED with the single byte
containing the DatabaseStore type (3). containing the DatabaseStore type (3).
@ -1202,7 +1205,7 @@ Notes
may parse the structure even if not all encryption types are known or supported. may parse the structure even if not all encryption types are known or supported.
JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/LeaseSet.html JavaDoc: http://{{ i2pconv('echelon.i2p/javadoc') }}/net/i2p/data/LeaseSet2.html
.. _struct-MetaLease: .. _struct-MetaLease:

6
i2p2www/spec/i2cp.rst
View File

@ -3,8 +3,8 @@ I2CP Specification
================== ==================
.. meta:: .. meta::
:category: Protocols :category: Protocols
:lastupdated: February 2020 :lastupdated: April 2020
:accuratefor: 0.9.44 :accuratefor: 0.9.46
.. contents:: .. contents::
@ -565,7 +565,7 @@ Contents
7. [PrivateKey]_ Decryption key 7. [PrivateKey]_ Decryption key
Only present if flag bit 0 is set to 1. Only present if flag bit 0 is set to 1.
A 32-byte ECIES_X25519 private key A 32-byte ECIES_X25519 private key, little-endian
8. [String]_ Lookup Password 8. [String]_ Lookup Password
Only present if flag bit 4 is set to 1. Only present if flag bit 4 is set to 1.

2
i2p2www/spec/i2np.rst
View File

@ -44,6 +44,8 @@ below.
============== ================================================================ ============== ================================================================
0.9.46 DatabaseLookup flag bit 4 for AEAD reply 0.9.46 DatabaseLookup flag bit 4 for AEAD reply
0.9.44 X25519 keys in LeaseSet2
0.9.40 MetaLeaseSet may be sent in a DSM 0.9.40 MetaLeaseSet may be sent in a DSM
0.9.39 EncryptedLeaseSet may be sent in a DSM 0.9.39 EncryptedLeaseSet may be sent in a DSM

208
i2p2www/spec/proposals/144-ecies-x25519-aead-ratchet.rst
View File

@ -5,7 +5,7 @@ ECIES-X25519-AEAD-Ratchet
:author: zzz, chisana, orignal :author: zzz, chisana, orignal
:created: 2018-11-22 :created: 2018-11-22
:thread: http://zzz.i2p/topics/2639 :thread: http://zzz.i2p/topics/2639
:lastupdated: 2020-04-25 :lastupdated: 2020-04-26
:status: Open :status: Open
:target: 0.9.46 :target: 0.9.46
:implementedin: 0.9.46 :implementedin: 0.9.46
@ -21,8 +21,8 @@ since the beginning of I2P, to replace ElGamal/AES+SessionTags.
It relies on previous work as follows: It relies on previous work as follows:
- Common structures spec - Common structures spec [Common]_
- I2NP spec - [I2NP]_ spec including LS2
- ElGamal/AES+Session Tags spec http://i2p-projekt.i2p/en/docs/how/elgamal-aes - ElGamal/AES+Session Tags spec http://i2p-projekt.i2p/en/docs/how/elgamal-aes
- http://zzz.i2p/topics/1768 new asymmetric crypto overview - http://zzz.i2p/topics/1768 new asymmetric crypto overview
- Low-level crypto overview https://geti2p.net/spec/cryptography - Low-level crypto overview https://geti2p.net/spec/cryptography
@ -30,13 +30,16 @@ It relies on previous work as follows:
- [NTCP2]_ [Prop111]_ - [NTCP2]_ [Prop111]_
- 123 New netDB Entries - 123 New netDB Entries
- 142 New Crypto Template - 142 New Crypto Template
- [Noise]_ protocol
- [Signal]_ double ratchet algorithm - [Signal]_ double ratchet algorithm
The goal is to support new encryption for end-to-end, The goal is to support new encryption for end-to-end,
destination-to-destination communication. destination-to-destination communication.
The design will use a Noise handshake and data phase incorporating Signal's double ratchet.
All references to Signal and Noise in this proposal are for background information only. All references to Signal and Noise in this proposal are for background information only.
Knowledge of Signal and Noise protocols is not required to either understand Knowledge of Signal and Noise protocols is not required to understand
or implement this proposal. or implement this proposal.
@ -71,7 +74,7 @@ As a review,
we added support for encryption types when we added support for signature types. we added support for encryption types when we added support for signature types.
The encryption type field is always zero, both in Destinations and RouterIdentities. The encryption type field is always zero, both in Destinations and RouterIdentities.
Whether to ever change that is TBD. Whether to ever change that is TBD.
Reference the common structures specification. Reference the common structures specification [Common]_.
@ -83,7 +86,7 @@ As a review, we use ElGamal for:
1) Tunnel Build messages (key is in RouterIdentity) 1) Tunnel Build messages (key is in RouterIdentity)
Replacement is not covered in this proposal. Replacement is not covered in this proposal.
See proposal 152. See proposal 152 [Prop152]_.
2) Router-to-router encryption of netdb and other I2NP msgs (Key is in RouterIdentity) 2) Router-to-router encryption of netdb and other I2NP msgs (Key is in RouterIdentity)
Depends on this proposal. Depends on this proposal.
@ -122,26 +125,13 @@ Goals
- Don't rely on Java jbigi to make DH efficient - Don't rely on Java jbigi to make DH efficient
- Minimize DH operations - Minimize DH operations
- Much more bandwidth-efficient than ElGamal (514 byte ElGamal block) - Much more bandwidth-efficient than ElGamal (514 byte ElGamal block)
- Eliminate several problems with session tags, including:
* Inability to use AES until the first reply
* Unreliability and stalls if tag delivery assumed
* Bandwidth inefficient, especially on first delivery
* Huge space inefficiency to store tags
* Huge bandwidth overhead to deliver tags
* Highly complex, difficult to implement
* Difficult to tune for various use cases
(streaming vs. datagrams, server vs. client, high vs. low bandwidth)
* Memory exhaustion vulnerabilities due to tag delivery
- Support new and old crypto on same tunnel if desired - Support new and old crypto on same tunnel if desired
- Recipient is able to efficiently distinguish new from old crypto coming down - Recipient is able to efficiently distinguish new from old crypto coming down
same tunnel same tunnel
- Others cannot distinguish new from old crypto - Others cannot distinguish new from old or future crypto
- Eliminate new vs. Existing Session length classification (support padding) - Eliminate new vs. Existing Session length classification (support padding)
- No new I2NP messages required - No new I2NP messages required
- Replace SHA-256 checksum in AES payload with AEAD - Replace SHA-256 checksum in AES payload with AEAD
- (Optimistic) Add extensions or hooks to support multicast
- Support binding of transmit and receive sessions so that - Support binding of transmit and receive sessions so that
acknowledgements may happen within the protocol, rather than solely out-of-band. acknowledgements may happen within the protocol, rather than solely out-of-band.
This will also allow replies to have forward secrecy immediately. This will also allow replies to have forward secrecy immediately.
@ -151,16 +141,28 @@ Goals
or Garlic Message Delivery Instructions format. or Garlic Message Delivery Instructions format.
- Eliminate unused or redundant fields in the Garlic Clove Set and Clove formats. - Eliminate unused or redundant fields in the Garlic Clove Set and Clove formats.
Eliminate several problems with session tags, including:
- Inability to use AES until the first reply
- Unreliability and stalls if tag delivery assumed
- Bandwidth inefficient, especially on first delivery
- Huge space inefficiency to store tags
- Huge bandwidth overhead to deliver tags
- Highly complex, difficult to implement
- Difficult to tune for various use cases
(streaming vs. datagrams, server vs. client, high vs. low bandwidth)
- Memory exhaustion vulnerabilities due to tag delivery
Non-Goals / Out-of-scope Non-Goals / Out-of-scope
------------------------ ------------------------
- LS2 format (see proposal 123) - LS2 format changes (proposal 123 is done)
- New DHT rotation algorithm or shared random generation - New DHT rotation algorithm or shared random generation
- New encryption for tunnel building. - New encryption for tunnel building.
See proposal 152. See proposal 152 [Prop152]_.
- New encryption for tunnel layer encryption. - New encryption for tunnel layer encryption.
See proposal 153. See proposal 153 [Prop153]_.
- Methods of encryption, transmission, and reception of I2NP DLM / DSM / DSRM messages. - Methods of encryption, transmission, and reception of I2NP DLM / DSM / DSRM messages.
Not changing. Not changing.
- No LS1-to-LS2 or ElGamal/AES-to-this-proposal communication is supported. - No LS1-to-LS2 or ElGamal/AES-to-this-proposal communication is supported.
@ -169,6 +171,7 @@ Non-Goals / Out-of-scope
using the same tunnels, or put both encryption types in the LS2. using the same tunnels, or put both encryption types in the LS2.
- Threat model changes - Threat model changes
- Implementation details are not discussed here and are left to each project. - Implementation details are not discussed here and are left to each project.
- (Optimistic) Add extensions or hooks to support multicast
@ -221,6 +224,7 @@ Detailed Proposal
================= =================
This proposal defines a new end-to-end protocol to replace ElGamal/AES+SessionTags. This proposal defines a new end-to-end protocol to replace ElGamal/AES+SessionTags.
The design will use a Noise handshake and data phase incorporating Signal's double ratchet.
Summary of Cryptographic Design Summary of Cryptographic Design
@ -265,11 +269,11 @@ Crypto Type
----------- -----------
The crypto type (used in the LS2) is 4. The crypto type (used in the LS2) is 4.
This indicates a 32-byte X25519 public key, This indicates a little-endian 32-byte X25519 public key,
and the end-to-end protocol specified here. and the end-to-end protocol specified here.
Crypto type 0 is ElGamal. Crypto type 0 is ElGamal.
Crypto types 1-3 are reserved for ECIES-ECDH-AES-SessionTag, see proposal 145. Crypto types 1-3 are reserved for ECIES-ECDH-AES-SessionTag, see proposal 145 [Prop145]_.
Noise Protocol Framework Noise Protocol Framework
@ -2463,8 +2467,8 @@ across ChaChaPoly frames.
{% endhighlight %} {% endhighlight %}
Notes Notes:
`````
- Implementers must ensure that when reading a block, - Implementers must ensure that when reading a block,
malformed or malicious data will not cause reads to malformed or malicious data will not cause reads to
overrun into the next block. overrun into the next block.
@ -2528,11 +2532,10 @@ Not allowed in NS or NSR. Only included in Existing Session messages.
{% endhighlight %} {% endhighlight %}
Notes Notes:
`````
Not all reasons may actually be used, implementation dependent. - Not all reasons may actually be used, implementation dependent.
Additional reasons listed are for consistency, logging, debugging, or if policy changes. - Additional reasons listed are for consistency, logging, debugging, or if policy changes.
@ -2577,8 +2580,8 @@ nine or more bytes, as more_options may be present.
{% endhighlight %} {% endhighlight %}
Options Notes Notes:
`````````````
- Support for non-default session tag length is optional, - Support for non-default session tag length is optional,
probably not necessary probably not necessary
@ -2586,8 +2589,8 @@ Options Notes
Options Issues Issues:
``````````````
- more_options format is TBD. - more_options format is TBD.
- Options negotiation is TBD. - Options negotiation is TBD.
- Padding parameters also? - Padding parameters also?
@ -2616,8 +2619,8 @@ The length (number of message keys) in the previous sending chain (PN).
{% endhighlight %} {% endhighlight %}
Notes Notes:
``````
- Maximum PN is 65535. - Maximum PN is 65535.
- The definitions of PN and N are identical to that in Signal. - The definitions of PN and N are identical to that in Signal.
@ -2668,17 +2671,16 @@ Not allowed in NS or NSR. Only included in Existing Session messages.
{% endhighlight %} {% endhighlight %}
Notes:
- Key ID is an incrementing counter for the local key used for that tag set, starting at 0.
Notes - The ID must not change unless the key changes.
`````` - It may not be strictly necessary, but it's useful for debugging.
- Signal does not use a key ID.
Key ID is an incrementing counter for the local key used for that tag set, starting at 0. - The maximum Key ID is 32767.
The ID must not change unless the key changes. - In the rare case that the tag sets in both directions are ratcheting at
It may not be strictly necessary, but it's useful for debugging. the same time, a frame will contain two Next Key blocks, one for
Signal does not use a key ID. the forward key and one for the reverse key.
The maximum Key ID is 32767.
Ack Ack
@ -2710,12 +2712,12 @@ Not allowed in NS or NSR. Only included in Existing Session messages.
{% endhighlight %} {% endhighlight %}
Notes Notes:
``````
The tag set ID and N uniquely identify the message being acked. - The tag set ID and N uniquely identify the message being acked.
In the first tag sets used for a session in each direction, the tag set ID is 0. - In the first tag sets used for a session in each direction, the tag set ID is 0.
No NextKey blocks have been sent, so there are no key IDs. - No NextKey blocks have been sent, so there are no key IDs.
For all tag sets used after NextKey exchanges, The tag set number is (1 + Alice's key ID + Bob's key ID). - For all tag sets used after NextKey exchanges, The tag set number is (1 + Alice's key ID + Bob's key ID).
@ -2776,8 +2778,8 @@ If present, this must be the last block in the frame.
{% endhighlight %} {% endhighlight %}
Notes Notes:
`````
- All-zero padding is fine, as it will be encrypted. - All-zero padding is fine, as it will be encrypted.
- Padding strategies TBD. - Padding strategies TBD.
- Padding-only frames are allowed. - Padding-only frames are allowed.
@ -3153,6 +3155,9 @@ Sessions must ratchet as they approach the limit of sent messages per-session (6
Implementation Considerations Implementation Considerations
============================= =============================
Defense
------------
As with the existing ElGamal/AES+SessionTag protocol, implementations must As with the existing ElGamal/AES+SessionTag protocol, implementations must
limit session tag storage and protect against memory exhaustion attacks. limit session tag storage and protect against memory exhaustion attacks.
@ -3166,15 +3171,35 @@ Some recommended strategies include:
- Refusal to ratchet when requested, if under memory pressure - Refusal to ratchet when requested, if under memory pressure
Parameters
------------
Identification at Receiver Recommended parameters and timeouts:
==========================
- NSR tagset size: 12 tsmin and tsmax
- ES tagset 0 size: tsmin 24, tsmax 160
- ES tagset (1+) size: 160 tsmin and tsmax
- NSR tagset timeout: 3 minutes for receiver
- ES tagset timeout: 12 minutes for sender, 15 minutes for receiver
- Remove previous ES tagset after: 3 minutes
- Tagset look ahead of tag N: min(tsmax, tsmin + N/4)
- Tagset trim behind tag N: min(tsmax, tsmin + N/4) / 2
- Send next key at tag: TBD
- Send next key after tagset lifetime: TBD
- Replace session if NS received after: 3 minutes
- Max clock skew: -5 minutes to +2 minutes
- NS replay filter duration: 5 minutes
- Padding size: 0-15 bytes (other strategies TBD)
Classification
------------------
Following are recommendations for classifying incoming messages. Following are recommendations for classifying incoming messages.
X25519 Only X25519 Only
----------- `````````````
On a tunnel that is solely used with this protocol, do identification On a tunnel that is solely used with this protocol, do identification
as is done currently with ElGamal/AES+SessionTags: as is done currently with ElGamal/AES+SessionTags:
@ -3187,7 +3212,7 @@ Perform a DH operation and the specified KDF, and attempt to decrypt the remaini
X25519 Shared with ElGamal/AES+SessionTags X25519 Shared with ElGamal/AES+SessionTags
------------------------------------------ ````````````````````````````````````````````
On a tunnel that supports both this protocol and On a tunnel that supports both this protocol and
ElGamal/AES+SessionTags, classify incoming messages as follows: ElGamal/AES+SessionTags, classify incoming messages as follows:
@ -3227,8 +3252,8 @@ Analysis
======== ========
Bandwidth overhead estimate Overhead
---------------------------- -----------
Message overhead for the first two messages in each direction are as follows. Message overhead for the first two messages in each direction are as follows.
This assumes only one message in each direction before the ACK, This assumes only one message in each direction before the ACK,
@ -3240,7 +3265,7 @@ No padding is assumed for analysis of the new protocol.
No bundled leaseset is assumed. No bundled leaseset is assumed.
For ElGamal/AES+SessionTags ElGamal/AES+SessionTags
``````````````````````````` ```````````````````````````
New session message, same each direction: New session message, same each direction:
@ -3294,7 +3319,7 @@ Four message total (two each direction)
{% endhighlight %} {% endhighlight %}
For ECIES-X25519-AEAD-Ratchet ECIES-X25519-AEAD-Ratchet
````````````````````````````` `````````````````````````````
Alice-to-Bob New Session message: Alice-to-Bob New Session message:
@ -3347,6 +3372,10 @@ Existing session messages, same each direction:
69 bytes 69 bytes
{% endhighlight %} {% endhighlight %}
Comparison
````````````````
Four message total (two each direction): Four message total (two each direction):
.. raw:: html .. raw:: html
@ -3377,8 +3406,8 @@ ElGamal: 158 + 32 byte tag sent previously = 190 bytes
{% endhighlight %} {% endhighlight %}
Processing overhead estimate CPU
---------------------------- ------
TODO update this section after proposal is stable. TODO update this section after proposal is stable.
@ -3403,8 +3432,8 @@ The following cryptographic operations are required by each party for each Exist
Session Tag Length Analysis Tag Length
--------------------------- --------------------
Current session tag length is 32 bytes. Current session tag length is 32 bytes.
We have not yet found any justification for that length, but we are continuing to research the archives. We have not yet found any justification for that length, but we are continuing to research the archives.
@ -3477,7 +3506,7 @@ While still extremely unlikely, they will be much more likely than
they were for ElGamal/AES+SessionTags, and could actually happen. they were for ElGamal/AES+SessionTags, and could actually happen.
Alternate analysis Alternate
`````````````````` ``````````````````
Using twice the sessions per second (128) and twice the tag window (64), Using twice the sessions per second (128) and twice the tag window (64),
@ -3493,8 +3522,8 @@ By reducing the target to 1 in 10,000, there's plenty of margin
with 8 byte tags. with 8 byte tags.
Storage Savings Storage
``````````````` ```````````
The sender generates tags and keys on the fly, so there is no storage. The sender generates tags and keys on the fly, so there is no storage.
This cuts overall storage requirements in half compared to ElGamal/AES. This cuts overall storage requirements in half compared to ElGamal/AES.
@ -3507,10 +3536,16 @@ Therefore, the total space savings vs. ElGamal/AES is a factor of 8, or 87%.
I2NP Changes Required Related Changes
===================== =====================
Database Lookups from ECIES Destinations: See [Prop154]_.
I2NP Changes Required
-----------------------
Database Lookups from ECIES Destinations: See [Prop154]_,
now incorporated in [I2NP]_ for release 0.9.46.
This proposal requires LS2 support to publish the X25519 public key with the leaseset. This proposal requires LS2 support to publish the X25519 public key with the leaseset.
No changes are required to the LS2 specifications in [I2NP]_. No changes are required to the LS2 specifications in [I2NP]_.
@ -3519,7 +3554,7 @@ All support was designed, specified, and implemented in [Prop123]_ implemented i
I2CP Changes Required I2CP Changes Required
===================== ------------------------
None. None.
This proposal requires LS2 support, and a property to be set in the I2CP options to be enabled. This proposal requires LS2 support, and a property to be set in the I2CP options to be enabled.
@ -3535,7 +3570,7 @@ or i2cp.leaseSetEncType=4,0 for ECIES and ElGamal dual keys.
I2CP Options I2CP Options
------------ ``````````````````
This section is copied from [Prop123]_. This section is copied from [Prop123]_.
@ -3550,7 +3585,7 @@ Option in SessionConfig Mapping:
Create Leaseset2 Message Create Leaseset2 Message
------------------------ ````````````````````````````
This proposal requires LS2 which is supported as of release 0.9.38. This proposal requires LS2 which is supported as of release 0.9.38.
No changes are required to the [I2CP]_ specifications. No changes are required to the [I2CP]_ specifications.
@ -3559,20 +3594,26 @@ All support was designed, specified, and implemented in [Prop123]_ implemented i
Publishing, Migration, Compatibility Compatibility
==================================== ------------------
Database Lookups from ECIES Destinations: See [Prop154]_.
Any router supporting LS2 with dual keys (0.9.38 or higher) should support Any router supporting LS2 with dual keys (0.9.38 or higher) should support
connection to destinations with dual keys. connection to destinations with dual keys.
ECIES-only destinations will require a majority of the floodfills to be updated
to 0.9.46 to get encrypted lookup replies. See [Prop154]_.
ECIES-only destinations can only connect with other destinations that are
either ECIES-only, or dual-key.
References References
========== ==========
.. [Common]
{{ spec_url('common-structures') }}
.. [Elligator2] .. [Elligator2]
https://elligator.cr.yp.to/elligator-20130828.pdf https://elligator.cr.yp.to/elligator-20130828.pdf
https://www.imperialviolet.org/2013/12/25/elligator.html https://www.imperialviolet.org/2013/12/25/elligator.html
@ -3602,6 +3643,15 @@ References
.. [Prop142] .. [Prop142]
{{ proposal_url('142') }} {{ proposal_url('142') }}
.. [Prop145]
{{ proposal_url('145') }}
.. [Prop152]
{{ proposal_url('152') }}
.. [Prop153]
{{ proposal_url('153') }}
.. [Prop154] .. [Prop154]
{{ proposal_url('154') }} {{ proposal_url('154') }}