kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

144 updates

Browse Source
This commit is contained in:
zzz
2019-05-27 12:57:22 +00:00
parent 738a9e6d7e
commit 10659295b1
1 changed files with 22 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@@ -5,7 +5,7 @@ ECIES-X25519-AEAD-Ratchet
:author: zzz
:created: 2018-11-22
:thread: http://zzz.i2p/topics/2639
:lastupdated: 2019-05-26
:lastupdated: 2019-05-27
:status: Open
.. contents::
@@ -1210,11 +1210,6 @@ Output of the encryption function, input to the decryption function:
| 16 bytes |
+----+----+----+----+----+----+----+----+
Obfs Len :: Length of (encrypted data + MAC) to follow, 16 - 65535
Obfuscation using SipHash (see below)
Not used in message 1 or 2, or message 3 part 1, where the length is fixed
Not used in message 3 part 1, as the length is specified in message 1
encrypted data :: Same size as plaintext data, 0 - 65519 bytes
MAC :: Poly1305 message authentication code, 16 bytes
@@ -1366,14 +1361,16 @@ Inputs:
// Output 1: Next chain key
sessTag_chainKey_0 = keydata_0[0:31]
// Output 2: The session tag
tag_0 = keydata_0[32:63]
// or more if tag is longer than 8 bytes
tag_0 = keydata_0[32:39]
// repeat as necessary to get to tag_n
keydata_n = HKDF(chainKey_(n-1), SESSTAG_CONSTANT, "SessionTagKeyGen", 64)
// Output 1: Next chain key
sessTag_chainKey_n = keydata_n[0:31]
// Output 2: The session tag
tag_n = keydata_n[32:63]
// or more if tag is longer than 8 bytes
tag_n = keydata_n[32:39]
{% endhighlight %}
@@ -2083,12 +2080,12 @@ Alice has three options:
1) Send the first message only (window size = 1), as in HTTP GET.
2) Send up to streaming window, but using same cleartext public key.
2) Send up to streaming window, but using same Elligator2-encoded cleartext public key.
All messages contain same next public key (ratchet).
This will be visible to OBGW/IBEP because they all start with the same cleartext.
Things proceed as in 1).
3) Send up to streaming window, but using a different cleartext public key (session) for each.
3) Send up to streaming window, but using a different Elligator2-encoded cleartext public key (session) for each.
All messages contain same next public key (ratchet).
This will not be visible to OBGW/IBEP because they all start with different cleartext.
Bob must recognize that they all contain the same next public key,
@@ -2415,6 +2412,21 @@ While still extremely unlikely, they will be much more likely than
they were for ElGamal/AES+SessionTags, and could actually happen.
Alternate analysis
``````````````````
Using twice the sessions per second (128) and twice the tag window (64),
we have 4 times the tags (7.4 million). Max for one in a million
chance of collision is 6.1 million tags.
12 byte (or even 10 byte) tags would add a huge margin.
However, is the one in a million chance of collision a good target?
Much larger than the chance of being dropped along the way is not much use.
The false-positive target for Java's DecayingBloomFilter is roughly
1 in 10,000, but even 1 in 1000 isn't of grave concern.
By reducing the target to 1 in 10,000, there's plenty of margin
with 8 byte tags.