From 616ed68e8c172de3b11b126abc41f4b42ed3d5b8 Mon Sep 17 00:00:00 2001 From: zzz Date: Mon, 23 Mar 2020 13:47:46 +0000 Subject: [PATCH] proposal 154 --- i2p2www/spec/proposals/154-ecies-lookups.rst | 386 +++++++++++++++++++ 1 file changed, 386 insertions(+) create mode 100644 i2p2www/spec/proposals/154-ecies-lookups.rst diff --git a/i2p2www/spec/proposals/154-ecies-lookups.rst b/i2p2www/spec/proposals/154-ecies-lookups.rst new file mode 100644 index 00000000..733a80fa --- /dev/null +++ b/i2p2www/spec/proposals/154-ecies-lookups.rst @@ -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') }} +