prop 123/144 edits
This commit is contained in:
@ -5,7 +5,7 @@ New netDB Entries
|
||||
:author: zzz, str4d, orignal
|
||||
:created: 2016-01-16
|
||||
:thread: http://zzz.i2p/topics/2051
|
||||
:lastupdated: 2018-12-02
|
||||
:lastupdated: 2018-12-03
|
||||
:status: Open
|
||||
:supercedes: 110, 120, 121, 122
|
||||
|
||||
@ -503,7 +503,7 @@ SIG
|
||||
TODO
|
||||
|
||||
DH
|
||||
Curve25519 public key agreement system. Pivate keys of 32 bytes,
|
||||
Curve25519 public key agreement system. Private keys of 32 bytes,
|
||||
public keys of 32 bytes, produces outputs of 32 bytes.
|
||||
|
||||
KDF(ikm, salt, info, n)
|
||||
@ -609,10 +609,11 @@ Signature
|
||||
|
||||
Layer 1 (middle)
|
||||
~~~~~~~~~~~~~~~~
|
||||
Flag
|
||||
1 byte
|
||||
|
||||
Per-client or for everybody?
|
||||
Flags :: 1 byte flags
|
||||
bit order: 76543210
|
||||
bit 0: 0 for everybody, 1 for per-client, auth section to follow
|
||||
bits 3-1: Authentication scheme, 0 for the scheme specified below
|
||||
bits 7-4: Unused, set to 0 for future compatibility
|
||||
|
||||
If per-client:
|
||||
ephemeralPublicKey
|
||||
@ -655,21 +656,21 @@ Data
|
||||
Blinding Key Derivation
|
||||
```````````````````````
|
||||
|
||||
We propose the following scheme for key blinding, based on Ed25519.
|
||||
|
||||
(This is an ECC group, so remember that scalar multiplication is the
|
||||
trapdoor function, and it's defined in terms of iterated point
|
||||
addition. See the Ed25519 paper [ED25519-REFS]_ for a fairly
|
||||
clear writeup.)
|
||||
|
||||
Copied from Tor rend-spec-v3.txt appendix A.2
|
||||
which has similar design goals [TOR-REND-SPEC-V3]_.
|
||||
|
||||
Adjustments TODO
|
||||
Changes for I2P TODO
|
||||
|
||||
|
||||
::
|
||||
|
||||
We propose the following scheme for key blinding, based on Ed25519.
|
||||
|
||||
(This is an ECC group, so remember that scalar multiplication is the
|
||||
trapdoor function, and it's defined in terms of iterated point
|
||||
addition. See the Ed25519 paper [ED25519-REFS]_ for a fairly
|
||||
clear writeup.)
|
||||
|
||||
Let B be the ed25519 basepoint as found in section 5 of [ED25519-B-REF]:
|
||||
B = (15112221349535400772501151409588531511454012693041857206046113283949847762202,
|
||||
46316835694926478169428394003475163141307993866256225615783033603165251855960)
|
||||
@ -716,9 +717,9 @@ Adjustments TODO
|
||||
|
||||
This boils down to regular Ed25519 with key pair (a', A').
|
||||
|
||||
See [KEYBLIND-REFS]_ for an extensive discussion on this scheme and
|
||||
possible alternatives. Also, see [KEYBLIND-PROOF]_ for a security
|
||||
proof of this scheme.
|
||||
See [KEYBLIND-REFS]_ for an extensive discussion on this scheme and
|
||||
possible alternatives. Also, see [KEYBLIND-PROOF]_ for a security
|
||||
proof of this scheme.
|
||||
|
||||
|
||||
|
||||
@ -764,6 +765,11 @@ Finally, the layer 1 plaintext is encrypted and serialized::
|
||||
|
||||
Layer 1 decryption
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='text' %}
|
||||
|
||||
The salt is parsed from the layer 1 ciphertext::
|
||||
|
||||
outerSalt = outerCiphertext[0..SALT_LEN]
|
||||
@ -779,6 +785,8 @@ Finally, the layer 1 ciphertext is decrypted::
|
||||
|
||||
outerPlaintext = DECRYPT(outerKey, outerIV, outerCiphertext[SALT_LEN..])
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
Layer 2 per-client authorization
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
TODO: Write up both DH-based client IDs and static client IDs, and pros/cons of each.
|
||||
@ -788,6 +796,11 @@ Layer 2 encryption
|
||||
When client authorization is enabled, ``authCookie`` is calculated as described above.
|
||||
When client authorization is disabled, ``authCookie`` is the zero-length byte array.
|
||||
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='text' %}
|
||||
|
||||
Encryption proceeds in a similar fashion to layer 1::
|
||||
|
||||
innerInput = blindedPublicKey || authCookie || subcredential || publishedTimestamp
|
||||
@ -797,11 +810,18 @@ Encryption proceeds in a similar fashion to layer 1::
|
||||
innerIV = keys[S_KEY_LEN..(S_KEY_LEN+S_IV_LEN)]
|
||||
innerCiphertext = innerSalt || ENCRYPT(innerKey, innerIV, innerPlaintext)
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
Layer 2 decryption
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
When client authorization is enabled, ``authCookie`` is calculated as described above.
|
||||
When client authorization is disabled, ``authCookie`` is the zero-length byte array.
|
||||
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='text' %}
|
||||
|
||||
Decryption proceeds in a similar fashion to layer 1::
|
||||
|
||||
innerInput = blindedPublicKey || authCookie || subcredential || publishedTimestamp
|
||||
@ -811,6 +831,7 @@ Decryption proceeds in a similar fashion to layer 1::
|
||||
innerIV = keys[S_KEY_LEN..(S_KEY_LEN+S_IV_LEN)]
|
||||
innerPlaintext = DECRYPT(innerKey, innerIV, innerCiphertext[SALT_LEN..])
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
Issues
|
||||
``````
|
||||
@ -1348,8 +1369,9 @@ Changes to support Offline Keys
|
||||
-------------------------------
|
||||
|
||||
TODO
|
||||
Offline signatures cannot be verified in streaming.
|
||||
Offline signatures cannot be verified in streaming or repliable datagrams.
|
||||
Needs some way to get the transient key via I2CP.
|
||||
Need some way to know you need to get the transient key.
|
||||
|
||||
|
||||
Streaming Changes Required
|
||||
@ -1358,6 +1380,18 @@ Streaming Changes Required
|
||||
TODO
|
||||
Offline signatures cannot be verified in streaming.
|
||||
Needs a flag to indicate offline signed.
|
||||
There is room in the header options bytes for a flag.
|
||||
Needs some way to get the transient key via I2CP.
|
||||
See I2CP section above.
|
||||
|
||||
|
||||
Repliable Datagram Changes Required
|
||||
===================================
|
||||
|
||||
TODO
|
||||
Offline signatures cannot be verified in the repliable datagram processing.
|
||||
Needs a flag to indicate offline signed but there's no place to put a flag.
|
||||
May require a completely new protocol number and format.
|
||||
Needs some way to get the transient key via I2CP.
|
||||
See I2CP section above.
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@ ECIES-X25519-AEAD-Ratchet
|
||||
:author: zzz
|
||||
:created: 2018-11-22
|
||||
:thread: http://zzz.i2p/topics/2639
|
||||
:lastupdated: 2018-12-01
|
||||
:lastupdated: 2018-12-03
|
||||
:status: Open
|
||||
|
||||
.. contents::
|
||||
@ -146,6 +146,10 @@ Non-Goals / Out-of-scope
|
||||
That would be in a separate proposal.
|
||||
- Methods of encryption, transmission, and reception of I2NP DLM / DSM / DSRM messages.
|
||||
Not changing.
|
||||
- No LS1-to-LS2 or ElGamal/AES-to-this-proposal communication is supported.
|
||||
This proposal is a bidirectional protocol.
|
||||
Destinations may handle backward compatibility by publishing two leasesets
|
||||
using the same tunnels, or put both encryption types in the LS2.
|
||||
- Threat model changes
|
||||
- Implementation details are not discussed here and are left to each project.
|
||||
|
||||
@ -498,6 +502,10 @@ The goal is to select a session tag length that is large enough
|
||||
to minimize the risk of collisions, while small enough
|
||||
to minimize memory usage.
|
||||
|
||||
This assumes that implementations limit session tag storage to
|
||||
prevent memory exhaustion attacks. This also will greatly reduce the chances that an attacker
|
||||
can create collisions. See the Implementation Considerations section below.
|
||||
|
||||
For a worst case, assume a busy server with 64 new inbound sessions per second.
|
||||
Assume 15 minute inbound session tag lifetime (same as now, probably should be reduced).
|
||||
Assume inbound session tag window of 32.
|
||||
@ -1185,6 +1193,11 @@ that have not yet been received.
|
||||
Once received, the stored key may be discarded, and if there are no previous
|
||||
unreceived tags, the window may be advanced.
|
||||
|
||||
For efficiency, the session tag and symmetric key ratchets should be separate so
|
||||
the session tag ratchet can run ahead of the symmetric key ratchet.
|
||||
This also provides some additional security, since the session tags go out on the wire.
|
||||
|
||||
|
||||
KDF:
|
||||
|
||||
.. raw:: html
|
||||
@ -1217,6 +1230,11 @@ once for the new key received, and once for the new key generated.
|
||||
Alice ratchets once when she receives the new key on the inbound session and replaces the corresponding outbound session.
|
||||
So each side ratchets twice total, in the typical case.
|
||||
|
||||
The frequency of ratchets after the initial handshake is implementation-dependent.
|
||||
While the protocol places a limit of 65535 messages before a ratchet is required,
|
||||
more frequent ratcheting (based on message count, elapsed time, or both)
|
||||
may provide additional security.
|
||||
|
||||
|
||||
KDF:
|
||||
|
||||
@ -1268,6 +1286,12 @@ Where appropriate, the same block numbers are used.
|
||||
We do not reuse NTCP2 block numbers for different uses, so
|
||||
that implementations may share code with NTCP2.
|
||||
|
||||
TODO there are concerns that encouraging implementers to share code
|
||||
may lead to parsing issues. Implementers should carefully consider
|
||||
the benefits and risks of sharing code, and ensure that the
|
||||
ordering and valid block rules are different for the two contexts.
|
||||
|
||||
|
||||
|
||||
Unencrypted data
|
||||
````````````````
|
||||
|
||||
Reference in New Issue
Block a user