prop 144 updates

This commit is contained in:
zzz
2019-04-03 20:35:36 +00:00
parent 60ad708468
commit ae3c26638b

View File

@ -5,7 +5,7 @@ ECIES-X25519-AEAD-Ratchet
:author: zzz :author: zzz
:created: 2018-11-22 :created: 2018-11-22
:thread: http://zzz.i2p/topics/2639 :thread: http://zzz.i2p/topics/2639
:lastupdated: 2019-03-31 :lastupdated: 2019-04-03
:status: Open :status: Open
.. contents:: .. contents::
@ -796,7 +796,7 @@ Encrypted:
Nonce :: 8 bytes, little endian? cleartext Nonce :: 8 bytes, little endian? cleartext
encrypted data 1 :: 40 bytes encrypted data 1 :: 55 bytes
MAC 1 :: Poly1305 message authentication code, 16 bytes MAC 1 :: Poly1305 message authentication code, 16 bytes
@ -809,34 +809,33 @@ Encrypted:
Decrypted data 1: Decrypted data 1:
.. raw:: html See AEAD section below.
Encrypted length is 71 bytes.
Decrypted length is 55 bytes.
Contents must be the following blocks in the following order:
{% highlight lang='dataspec' %} ================================== ============= ============
+----+----+----+----+----+----+----+----+ Payload Block Type Type Number Block Length
| | ================================== ============= ============
+ + Options 5 9
| DH Ratchet Public Key | Message Number 6 9
+ + Next Key 7 37
| | ================================== ============= ============
+ + Block Total 55
| | HMAC 16
+----+----+----+----+----+----+----+----+ Total 71
| Flags IV sequence number TODO | ================================== ============= ============
+----+----+----+----+----+----+----+----+
Public Key :: 32 bytes, little endian
TODO :: 8 bytes
{% endhighlight %}
Decrypted data 2: Decrypted data 2:
See AEAD section below. See AEAD section below.
Encrypted length is the remainder of the data.
Decrypted length is 16 less than the encrypted length.
All types are supported.
@ -1363,11 +1362,9 @@ KDF:
This replaces the AES section format defined in the ElGamal/AES+SessionTags specification. This replaces the AES section format defined in the ElGamal/AES+SessionTags specification.
This uses the same block format as defined in the NTCP2 specification. This uses the same block format as defined in the NTCP2 specification.
Where appropriate, the same block numbers are used. Individual block types are defined differently.
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 There are concerns that encouraging implementers to share code
may lead to parsing issues. Implementers should carefully consider may lead to parsing issues. Implementers should carefully consider
the benefits and risks of sharing code, and ensure that the the benefits and risks of sharing code, and ensure that the
ordering and valid block rules are different for the two contexts. ordering and valid block rules are different for the two contexts.
@ -1434,9 +1431,23 @@ so the max unencrypted data is 65519 bytes.
Block Ordering Rules Block Ordering Rules
```````````````````` ````````````````````
In the new session message, order must be: In first decrypted part of the new session message,
TBD the following three blocks are required, in the following order:
xx, followed by Options if present, followed by Padding if present.
- Options (type 5) (must be total length = 9)
- Message Number (type 6)
- New Key (type 7)
No other blocks are allowed.
In second decrypted part of the new session message,
three blocks are required, and padding is optional, in the following order:
- Message Number (type 6)
- New Key (type 7)
- I2NP message (type 3) (one or more)
- Padding (type 254)
No other blocks are allowed. No other blocks are allowed.
In the existing session message, order is unspecified, except for the In the existing session message, order is unspecified, except for the