prop 123/144 edits

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: 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
+Flags :: 1 byte flags
-    1 byte
+         bit order: 76543210
-
+         bit 0: 0 for everybody, 1 for per-client, auth section to follow
-    Per-client or for everybody?
+         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
+See [KEYBLIND-REFS]_ for an extensive discussion on this scheme and
-  possible alternatives. Also, see [KEYBLIND-PROOF]_ for a security
+possible alternatives. Also, see [KEYBLIND-PROOF]_ for a security
-  proof of this scheme.
+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.
 

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

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