proposal updates
This commit is contained in:
@ -5,7 +5,7 @@ ECIES-X25519-AEAD-Ratchet
|
||||
:author: zzz, chisana
|
||||
:created: 2018-11-22
|
||||
:thread: http://zzz.i2p/topics/2639
|
||||
:lastupdated: 2020-03-29
|
||||
:lastupdated: 2020-03-31
|
||||
:status: Open
|
||||
|
||||
.. contents::
|
||||
@ -2651,7 +2651,7 @@ Issues
|
||||
|
||||
Ack
|
||||
```
|
||||
This is only if an explicit ack was requested by the far end.
|
||||
This is only sent if an ack request block was received.
|
||||
Multiple acks may be present to ack multiple messages.
|
||||
|
||||
|
||||
@ -2688,35 +2688,25 @@ Issues
|
||||
|
||||
Ack Request
|
||||
```````````
|
||||
Delivery instructions for the ack.
|
||||
Request an in-band ack.
|
||||
To replace the out-of-band DeliveryStatus Message in the Garlic Clove.
|
||||
Also (optionally) binds the outbound session to the far-end Destination or Router.
|
||||
|
||||
If an explicit ack is requested, the current key ID and message number (N)
|
||||
are returned in an ack block. When a next public key is included,
|
||||
any message sent to that key constitutes an ack, no explicit ack is required.
|
||||
If an explicit ack is requested, the current tagset ID and message number (N)
|
||||
are returned in an ack block.
|
||||
|
||||
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='dataspec' %}
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| 9 | size |tagsetid |flg | |
|
||||
+----+----+----+----+----+----+ +
|
||||
Garlic Clove Delivery Instructions |
|
||||
~ . . . ~
|
||||
| optional if flag is 1 |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
+----+----+----+----+
|
||||
| 9 | size |flg |
|
||||
+----+----+----+----+
|
||||
|
||||
blk :: 9
|
||||
size :: varies, typically 3 or 36
|
||||
tagsetid :: key ID, 2 bytes, big endian
|
||||
size :: 1
|
||||
flg :: 1 byte flags
|
||||
bit order: 76543210
|
||||
bits 7-0: Unused, set to 0 for future compatibility
|
||||
Delivery Instructions :: as defined in I2NP spec, 33 bytes for DESTINATION type
|
||||
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
@ -2726,33 +2716,12 @@ Notes
|
||||
|
||||
- Not allowed in NS or NSR. Only included in Existing Session mnessages
|
||||
|
||||
- tagsetid is known to receiver, TBD to remove
|
||||
|
||||
- Delivery Instructions unused, TBD to remove
|
||||
|
||||
- Interaction with next key TBD
|
||||
|
||||
- When the delivery instructions contains the hash of the destination,
|
||||
and the session is not previously bound, this binds the session to the destination.
|
||||
|
||||
- After a session is bound, any subsequent destination delivery instructions must contain
|
||||
the same hash as previously, or this is an error.
|
||||
|
||||
- See ACK section above for more information.
|
||||
|
||||
|
||||
Issues
|
||||
``````
|
||||
|
||||
- Java router must have the actual signing private key, not a dummy,
|
||||
see new I2CP Create LeaseSet2 Message in proposal 123.
|
||||
|
||||
- For easier processing, LS clove should precede Garlic clove in the message.
|
||||
|
||||
- Is the next public key the right thing to sign?
|
||||
|
||||
- Use alice's static pubkey instead?
|
||||
|
||||
|
||||
|
||||
Padding
|
||||
|
||||
@ -5,7 +5,7 @@ Database Lookups from ECIES Destinations
|
||||
:author: zzz
|
||||
:created: 2020-03-23
|
||||
:thread: http://zzz.i2p/topics/2856
|
||||
:lastupdated: 2020-03-29
|
||||
:lastupdated: 2020-03-31
|
||||
:status: Open
|
||||
|
||||
.. contents::
|
||||
@ -123,14 +123,15 @@ Add flag bit 4 "ECIESFlag" for the new encryption options.
|
||||
{% highlight lang='dataspec' %}
|
||||
flags ::
|
||||
bit 4: ECIESFlag
|
||||
before release 0.9.TBD, ignored
|
||||
as of release 0.9.TBD:
|
||||
before release 0.9.46 ignored
|
||||
as of release 0.9.46:
|
||||
0 => send unencrypted or ElGamal reply
|
||||
1 => send ECIES encrypted reply using enclosed key and tag
|
||||
1 => send ChaCha/Poly encrypted reply using enclosed key
|
||||
(whether tag is enclosed depends on bit 1)
|
||||
{% endhighlight %}
|
||||
|
||||
Existing flag bit 1 used in combination with bit 4 to determine the reply encryption mode.
|
||||
Flag bit 4 must only be set when sending to routers with version 0.9.TBD or higher.
|
||||
Flag bit 4 must only be set when sending to routers with version 0.9.46 or higher.
|
||||
|
||||
|
||||
============= ========= ========= ====== === =======
|
||||
@ -189,6 +190,7 @@ ECIES to ElG
|
||||
------------
|
||||
|
||||
ECIES destination sends a lookup to a ElG router.
|
||||
Supported as of 0.9.46.
|
||||
|
||||
The reply_key and reply_tags fields are redefined for an ECIES-encrypted reply.
|
||||
|
||||
@ -209,17 +211,17 @@ Redefine reply_key and reply_tags fields as follows:
|
||||
{% highlight lang='dataspec' %}
|
||||
reply_key ::
|
||||
32 byte ECIES `SessionKey` big-endian
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.TBD
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.46
|
||||
|
||||
tags ::
|
||||
1 byte `Integer`
|
||||
required value: 1
|
||||
the number of reply tags that follow
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.TBD
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.46
|
||||
|
||||
reply_tags ::
|
||||
an 8 byte ECIES `SessionTag`
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.TBD
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.46
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
@ -234,7 +236,7 @@ tag :: 8 byte reply_tag
|
||||
k :: 32 byte session key
|
||||
The reply_key.
|
||||
|
||||
n :: The index of the reply_tag. Typically 0.
|
||||
n :: 0
|
||||
|
||||
ad :: Associated data. ZEROLEN.
|
||||
|
||||
@ -252,6 +254,7 @@ ECIES to ECIES
|
||||
--------------
|
||||
|
||||
ECIES destination sends a lookup to a ECIES router.
|
||||
Supported as of 0.9.TBD.
|
||||
|
||||
The lookup will use the "one time format" in [ECIES]_
|
||||
as the requester is anonymous.
|
||||
@ -383,6 +386,8 @@ The above proposal is the easiest and minimizes the change to the lookup format.
|
||||
Notes
|
||||
=====
|
||||
|
||||
Database lookups and stores to ElG routers must be ElGamal/AESSessionTag encrypted
|
||||
as usual.
|
||||
|
||||
|
||||
Issues
|
||||
@ -395,11 +400,12 @@ Further analysis is required on the security of the two ECIES reply options.
|
||||
Migration
|
||||
=========
|
||||
|
||||
No backward compatibility issues. Routers advertising a router.version of 0.9.TBD or higher
|
||||
No backward compatibility issues. Routers advertising a router.version of 0.9.46 or higher
|
||||
in their RouterInfo must support this feature.
|
||||
Routers must not send a DatabaseLookup with the new flags to routers with a version less than 0.9.TBD.
|
||||
|
||||
|
||||
Routers must not send a DatabaseLookup with the new flags to routers with a version less than 0.9.46.
|
||||
If a database lookup message with bit 4 set and bit 1 unset is mistakenly sent to
|
||||
a router without support, it will probably ignore the supplied key and tag, and
|
||||
sent the reply unencrypted.
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
Reference in New Issue
Block a user