I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
616ed68e8c172de3b11b126abc41f4b42ed3d5b8
i2p.www/i2p2www/spec/proposals/154-ecies-lookups.rst

387 lines
10 KiB
ReStructuredText
Raw Normal View History

proposal 154
2020-03-23 13:47:46 +00:00
========================================
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 Copy Permalink