forked from I2P_Developers/i2p.www
proposal 154
This commit is contained in:
386
i2p2www/spec/proposals/154-ecies-lookups.rst
Normal file
386
i2p2www/spec/proposals/154-ecies-lookups.rst
Normal file
@@ -0,0 +1,386 @@
|
||||
========================================
|
||||
Database Lookups from ECIES Destinations
|
||||
========================================
|
||||
.. meta::
|
||||
:author: zzz
|
||||
:created: 2020-03-23
|
||||
:thread: http://zzz.i2p/topics/2856
|
||||
:lastupdated: 2020-03-23
|
||||
:status: Open
|
||||
|
||||
.. contents::
|
||||
|
||||
|
||||
Definitions
|
||||
===========
|
||||
|
||||
- AEAD: ChaCha20/Poly1305
|
||||
- DLM: I2NP Database Lookup Message
|
||||
- DSM: I2NP Database Store Message
|
||||
- DSRM: I2NP Database Search Reply Message
|
||||
- ECIES: ECIES-X25510-AEAD-Ratchet (propoosal 144)
|
||||
- ElG: ElGamal
|
||||
- ENCRYPT(k, n, payload, ad): As defined in [ECIES]_
|
||||
- LS: Leaseset
|
||||
- lookup: I2NP DLM
|
||||
- reply: I2NP DSM or DSRM
|
||||
|
||||
|
||||
Overview
|
||||
========
|
||||
|
||||
When sending a DLM for a LS to a floodfill, the DLM generally specifies
|
||||
that the reply be tagged, AES encrypted, and sent down a tunnel to the destination.
|
||||
Support for AES-encrypted replies was added in 0.9.7.
|
||||
|
||||
AES-encrypted replies were specified in 0.9.7 to minimize the large crypto
|
||||
overhead of ElG, and because it reused the tags/AES facility
|
||||
in ElGamal/AES+SessionTags.
|
||||
However, AES replies may be tampered with at the IBEP as there is no authentication,
|
||||
and the replies are not forward secret.
|
||||
|
||||
With [ECIES]_ destinations, the intent of proposal 144 is that
|
||||
the destinations no longer support 32-byte tags and AES decryption.
|
||||
The specifics were intentionally not included in that proposal.
|
||||
|
||||
This proposal documents a new option in the DLM to request ECIES-encrypted replies.
|
||||
|
||||
|
||||
Goals
|
||||
=====
|
||||
|
||||
- New flags for DLM when an encrypted reply is requested down a tunnel to a ECIES destination
|
||||
- For the reply, add forward secrecy and sender authentication resistant to
|
||||
the requester's (destination) key compromise impersonation (KCI).
|
||||
- Maintain anonymity of requester
|
||||
- Minimize crypto overhead
|
||||
|
||||
Non-Goals
|
||||
=========
|
||||
|
||||
- No change to the encryption or security properties of the lookup (DLM).
|
||||
The lookup has forward secrecy for requester key compromise only.
|
||||
The encryption is to the floodfill's static key.
|
||||
- No forward secrecy or sender authentication issues resistant to
|
||||
the responder's (floodfill's) key compromise impersonation (KCI).
|
||||
The floodfill is a public database and will respond to lookups
|
||||
from anybody.
|
||||
- Don't design ECIES routers in this proposal.
|
||||
Where a router's X25519 public key goes is TBD.
|
||||
|
||||
|
||||
Alternatives
|
||||
============
|
||||
|
||||
In the absence of a defined way to encrypt replies to ECIES destinations, there
|
||||
are three alternatives:
|
||||
|
||||
1) Do not request encrypted replies. Replies will be unencrypted.
|
||||
Java I2P currently uses this approach.
|
||||
|
||||
2) Add support for 32-byte tags and AES-encrypted replies to ECIES-only destinations,
|
||||
and request AES-encrypted replies as usual. i2pd currently uses this approach.
|
||||
|
||||
3) For dual ElG and ECIES destinations,
|
||||
request AES-encrypted replies as usual. Java I2P currently uses this approach.
|
||||
i2pd has not yet implemented dual-crypto destinations.
|
||||
|
||||
|
||||
|
||||
Design
|
||||
======
|
||||
|
||||
- New DLM format will add a bit to the flags field to specify ECIES-encrypted replies.
|
||||
ECIES-encrypted replies will use the [ECIES]_ Existing Session message format,
|
||||
with a prepended tag and a ChaCha/Poly payload and MAC.
|
||||
|
||||
- Define two variants. One for ElG routers, where a DH operation is not possible,
|
||||
and one for future ECIES routers, where a DH operation is possible and may provide
|
||||
additional security. For further study.
|
||||
|
||||
DH is not possible for replies from ElG routers because they do not publish
|
||||
a X25519 public key.
|
||||
|
||||
|
||||
|
||||
|
||||
Specification
|
||||
=============
|
||||
|
||||
In the [I2NP]_ DLM (DatabaseLookup) specification, make the following changes.
|
||||
|
||||
|
||||
Add flag bit 4 "ECIESFlag" for more encryption options.
|
||||
Existing flag bit 1 used in combination with bit 4 to determine the reply encryption mode.
|
||||
Flag bit 4 must only be set when sending to routers with version 0.9.TBD or higher.
|
||||
|
||||
|
||||
============= ========= ========= ====== === =======
|
||||
Flag bits 4/1 From Dest To Router Reply DH? notes
|
||||
============= ========= ========= ====== === =======
|
||||
0 0 Any Any no enc. no current
|
||||
0 1 ElG ElG AES no current
|
||||
0 1 ECIES ElG AES no i2pd workaround
|
||||
1 0 ECIES ElG AEAD no new, no DH
|
||||
1 1 ECIES ECIES AEAD yes future, with DH
|
||||
============= ========= ========= ====== === =======
|
||||
|
||||
|
||||
ElG to ElG
|
||||
----------
|
||||
|
||||
Minor changes.
|
||||
|
||||
Requester key generation (clarification):
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='dataspec' %}
|
||||
reply_key :: CSRNG(32) 32 bytes random data
|
||||
reply_tags :: Each is CSRNG(32) 32 bytes random data
|
||||
{% endhighlight %}
|
||||
|
||||
Message format:
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='dataspec' %}
|
||||
reply_key ::
|
||||
32 byte `SessionKey` big-endian
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.7
|
||||
|
||||
tags ::
|
||||
1 byte `Integer`
|
||||
valid range: 1-32 (typically 1)
|
||||
the number of reply tags that follow
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.7
|
||||
|
||||
reply_tags ::
|
||||
one or more 32 byte `SessionTag`s (typically one)
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.7
|
||||
{% endhighlight %}
|
||||
|
||||
|
||||
|
||||
|
||||
ECIES to ElG
|
||||
------------
|
||||
|
||||
The reply_key and reply_tags fields are redefined for an ECIES-encrypted reply.
|
||||
|
||||
Requester key generation:
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='dataspec' %}
|
||||
reply_key :: CSRNG(32) 32 bytes random data
|
||||
reply_tags :: Each is CSRNG(8) 8 bytes random data
|
||||
{% endhighlight %}
|
||||
|
||||
Message format:
|
||||
Redefine reply_key and reply_tags fields as follows:
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='dataspec' %}
|
||||
reply_key ::
|
||||
32 byte ECIES `SessionKey` big-endian
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.TBD
|
||||
|
||||
tags ::
|
||||
1 byte `Integer`
|
||||
valid range: 1-32 (typically 1)
|
||||
the number of reply tags that follow
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.TBD
|
||||
|
||||
reply_tags ::
|
||||
one or more 8 byte ECIES `SessionTag`s (typically one)
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 0, only as of release 0.9.TBD
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
|
||||
The reply is an ECIES Existing Session message, as defined in [ECIES]_.
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='dataspec' %}
|
||||
tag :: 8 byte reply_tag
|
||||
|
||||
k :: 32 byte session key
|
||||
The reply_key.
|
||||
|
||||
n :: The index of the reply_tag. Typically 0.
|
||||
|
||||
ad :: Associated data. ZEROLEN.
|
||||
|
||||
payload :: Plaintext data, the DSM or DSRM.
|
||||
|
||||
ciphertext = ENCRYPT(k, n, payload, ad)
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
ECIES to ECIES
|
||||
--------------
|
||||
|
||||
The lookup will use the "one time format" in [ECIES]_
|
||||
as the requester is anonymous.
|
||||
|
||||
Redefine reply_key field as follows. There are no associated tags.
|
||||
The tags will be generated in the KDF below.
|
||||
|
||||
This section is incomplete and requires further study.
|
||||
ECIES routers do not yet exist and there is no documented proposal
|
||||
for ECIES routers at this time.
|
||||
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='dataspec' %}
|
||||
reply_key ::
|
||||
32 byte X25519 ephemeral `PublicKey` of the requester, little-endian
|
||||
only included if encryptionFlag == 1 AND ECIESFlag == 1, only as of release 0.9.TBD
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
The reply is an ECIES Existing Session message, as defined in [ECIES]_.
|
||||
See [ECIES]_ for all definitions.
|
||||
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='dataspec' %}
|
||||
// Alice's X25519 ephemeral keys
|
||||
// aesk = Alice ephemeral private key
|
||||
aesk = GENERATE_PRIVATE()
|
||||
// aepk = Alice ephemeral public key
|
||||
aepk = DERIVE_PUBLIC(aesk)
|
||||
// Bob's X25519 static keys
|
||||
// bsk = Bob private static key
|
||||
bsk = GENERATE_PRIVATE()
|
||||
// bpk = Bob public static key
|
||||
// bpk is either part of RouterIdentity, or published in RouterInfo (TBD)
|
||||
bpk = DERIVE_PUBLIC(bsk)
|
||||
|
||||
// (DH()
|
||||
//[chainKey, k] = MixKey(sharedSecret)
|
||||
// chainKey from ???
|
||||
sharedSecret = DH(aesk, bpk) = DH(bsk, aepk)
|
||||
keydata = HKDF(chainKey, sharedSecret, "ECIES-DSM-Reply1", 32)
|
||||
chainKey = keydata[0:31]
|
||||
|
||||
1) rootKey = chainKey from Payload Section
|
||||
2) k from the New Session KDF or split()
|
||||
|
||||
// KDF_RK(rk, dh_out)
|
||||
keydata = HKDF(rootKey, k, "KDFDHRatchetStep", 64)
|
||||
|
||||
// Output 1: unused
|
||||
unused = keydata[0:31]
|
||||
// Output 2: The chain key to initialize the new
|
||||
// session tag and symmetric key ratchets
|
||||
// for Alice to Bob transmissions
|
||||
ck = keydata[32:63]
|
||||
|
||||
// session tag and symmetric key chain keys
|
||||
keydata = HKDF(ck, ZEROLEN, "TagAndKeyGenKeys", 64)
|
||||
sessTag_ck = keydata[0:31]
|
||||
symmKey_ck = keydata[32:63]
|
||||
|
||||
tag :: 8 byte tag as generated from RATCHET_TAG() in [ECIES]_
|
||||
|
||||
k :: 32 byte key as generated from RATCHET_KEY() in [ECIES]_
|
||||
|
||||
n :: The index of the tag. Typically 0.
|
||||
|
||||
ad :: Associated data. ZEROLEN.
|
||||
|
||||
payload :: Plaintext data, the DSM or DSRM.
|
||||
|
||||
ciphertext = ENCRYPT(k, n, payload, ad)
|
||||
{% endhighlight %}
|
||||
|
||||
|
||||
|
||||
Reply format
|
||||
------------
|
||||
|
||||
This is the existing session message,
|
||||
same as in [ECIES]_, copied below for reference.
|
||||
|
||||
.. raw:: html
|
||||
|
||||
{% highlight lang='dataspec' %}
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| Session Tag |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| |
|
||||
+ Payload Section +
|
||||
| ChaCha20 encrypted data |
|
||||
~ ~
|
||||
| |
|
||||
+ +
|
||||
| |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
| Poly1305 Message Authentication Code |
|
||||
+ (MAC) +
|
||||
| 16 bytes |
|
||||
+----+----+----+----+----+----+----+----+
|
||||
|
||||
Session Tag :: 8 bytes, cleartext
|
||||
|
||||
Payload Section encrypted data :: remaining data minus 16 bytes
|
||||
|
||||
MAC :: Poly1305 message authentication code, 16 bytes
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
|
||||
Justification
|
||||
=============
|
||||
|
||||
The reply encryption parameters in the lookup, first introduced in 0.9.7,
|
||||
are somewhat of a layering violation. It's done this way for efficiency.
|
||||
But also because the lookup is anonymous.
|
||||
|
||||
We could make the lookup format generic, like with an encryption type field,
|
||||
but that's probably more trouble than it's worth.
|
||||
|
||||
The above proposal is the easiest and minimizes the change to the lookup format.
|
||||
|
||||
|
||||
|
||||
Notes
|
||||
=====
|
||||
|
||||
|
||||
|
||||
Issues
|
||||
======
|
||||
|
||||
Further analysis is required on the security of the two ECIES reply options.
|
||||
|
||||
|
||||
|
||||
Migration
|
||||
=========
|
||||
|
||||
No backward compatibility issues. Routers advertising a router.version of 0.9.TBD or higher
|
||||
in their RouterInfo must support this feature.
|
||||
Routers must not send a DatabaseLookup with the new flags to routers with a version less than 0.9.TBD.
|
||||
|
||||
|
||||
|
||||
References
|
||||
==========
|
||||
|
||||
.. [ECIES]
|
||||
{{ proposal_url('144') }}
|
||||
|
||||
.. [I2NP]
|
||||
{{ spec_url('i2np') }}
|
||||
|
||||
Reference in New Issue
Block a user