prop 123/144 edits

This commit is contained in:
zzz
2018-12-03 21:46:08 +00:00
parent 13287028d7
commit 0b4fa53433
2 changed files with 77 additions and 19 deletions

View File

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

View File

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