From a93c55469da89a66d9fbcce9d72491bd522a4623 Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 09:42:39 -0400 Subject: [PATCH 01/19] first commit for encryption --- EIPS/eip-5605.md | 144 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 144 insertions(+) create mode 100644 EIPS/eip-5605.md diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md new file mode 100644 index 0000000000000..df65c63098dbb --- /dev/null +++ b/EIPS/eip-5605.md @@ -0,0 +1,144 @@ +--- +eip: +title: New approach for encryption / decryption +author: Firn Protocol , Fried L. Trout +status: Draft +type: Standards Track +created: 2022-09-07 +--- + + +### Abstract + +This EIP proposes a new way to encrypt and decrypt using Ethereum keys, which remedies the shortcomings of the now-stagnant [EIP-1024](https://github.com/topealabi/EIPs/blob/encryption/EIPS/eip-1024.md). +This proposal uses separate, unlinkable, pseudorandom keys for signing and encryption; it uses _only_ the `secp256k1` curve, and it uses a standardized version of ECIES (see e.g. [Brown, [SEC 1, § 5.1]](https://www.secg.org/sec1-v2.pdf) and [ANSI X9.63, § 5.8](https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017?source=preview)). +In contrast, EIP-1024 reused secret keys across both signing and encryption, and moreover reused the same secret key across both the `secp256k1` and `ec25519` curves. + +### Motivation +Some motivation for introducing encryption to Ethereum has already been discussed in [EIP-1024](https://github.com/topealabi/EIPs/blob/encryption/EIPS/eip-1024.md). + +To that discussion, we add a few further motivating examples. In a certain very common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain). +This design pattern allows the dApp/user to bootstrap the security of the _fresh_ secret onto the security of the user's existing HD wallet seed phrase, which the user has already gone through the trouble of safeguarding and storing. This represents a far lower UX burden than forcing the user to store and manage fresh keys directly (which can, and often does, lead to loss of funds). We note that this _exact_ design pattern described above is used today by, e.g., Tornado Cash. + +As a separate motivation, we mention the possibility of dApps which facilitate end-to-end encrypted messaging. + +### Specification +We describe our approach here; we compare our approach to EIP-1024's in the **Rationale** section below. + +We use the `secp256k1` curve for both signing and encryption (with different keys, see below). +In the latter case, we use ECIES; specifically, we use a standardized variant, which appears e.g. in [Brown, [SEC 1, § 5.1]](https://www.secg.org/sec1-v2.pdf). +Specifically, we propose the choices: +- the KDF `ANSI-X9.63-KDF`, where the hash function `SHA-512` is used (see [[SEC 1, § 3.6]](https://www.secg.org/sec1-v2.pdf)), +- the HMAC `HMAC–SHA-256–256 with 32 octet or 256 bit keys` (see [[SEC 1, § 3.7]](https://www.secg.org/sec1-v2.pdf)), +- the symmetric encryption scheme `AES–256 in CBC mode` (see [[SEC 1, § 3.8]](https://www.secg.org/sec1-v2.pdf)). + +We finally describe a method to derive encryption secret keys deterministically—but pseudorandomly—from signing keys, in such a way that a natural one-to-one relationship obtains between these keys (this latter property is essential, since it allows Ethereum accounts to be used as handles onto encryption/decryption keys, as both the former and current API interfaces do). +Indeed, we propose that, given a signing private key _sk_ ∈ 𝔽_q—which is naturally represented as a 32-byte big-endian byte string (see [[SEC 1, § 2.3.6–2.3.7]](https://www.secg.org/sec1-v2.pdf)) —the corresponding decryption key _dk_ ∈ 𝔽_q be generated as the 32-byte secret: + + dk := ANSI-X9.63-KDF(sk), +where moreover the _Ethereum `keccak256`_ hash is used for this KDF. This latter decision is essentially for implementation convenience; indeed, MetaMask's `eth-simple-keyring` already has something close to this functionality [built in](https://github.com/MetaMask/eth-simple-keyring/blob/f8c9105825953e926480e84c001e30ded5e8ebdf/index.js#L185-L192), and it requires only a minimal code change (see also our implementation below). +We set _SharedInfo_ to be empty here. + +We propose that the binary, _concatenated_ serialization mode for ECIES ciphertexts be used (see [[SEC 1, § 5.1.3, 8.]](https://www.secg.org/sec1-v2.pdf)), both for encryption and decryption, where moreover elliptic curve points are _compressed_. This approach is considerably more space-efficient than the prior approach, which outputted a stringified JSON object (itself containing base64-encoded fields). +We moreover propose that binary data be serialized to and from `0x`-prefixed hex strings. We moreover use `0x`-prefixed hex strings to specify private keys and public keys, and represent public keys in compressed form. We represent Ethereum accounts in the usual way (`0x`-prefixed, 20-byte hex strings). + +Thus, on the request: +```javascript +request({ + method: 'eth_getEncryptionPublicKey', + params: [account], +}) +``` +where `account` is a standard 20-byte, `0x`-prefixed, hex-encoded Ethereum account, the client should operate as follows: + - find the secret signing key `sk` corresponding to the Ethereum account `account`, or else return an error if none exists. + - compute the 32-byte secret `dk := ANSI-X9.63-KDF(sk)`, where the `keccak256` hash is used in the KDF. + - compute the `secp256k1` public key corresponding to `dk`. + - return this public key in compressed, `0x`-prefixed, hex-encoded form. + +On the request +```javascript +request({ + method: 'eth_decrypt', + params: [encryptedMessage, account], +}) +``` +where `account` is as above, and `encryptedMessage` is a JSON object with the properties `version` (an arbitrary string) and `ciphertext` (a `0x`-prefixed, hex-encoded, bytes-like string), the client should operate as follows: + - perform a `switch` on the value `encryptedMessage.version`. if it equals: + - `x25519-xsalsa20-poly1305`, then use EIP-1024's specification; + - `secp256k1-sha512kdf-aes256cbc-hmacsha256`, then proceed as described below; + - if it equals neither, throw an error. + - find the secret key `sk` corresponding to the Ethereum account `account`, or else return an error if none exists. + - compute the 32-byte secret `dk := ANSI-X9.63-KDF(sk)`, where the `keccak256` hash is used in the KDF. + - using `dk`, perform an ECIES decryption of `encryptedMessage.ciphertext`, where the above choices of parameters are used. + - decode the resulting binary plaintext as a `utf-8` string, and return it. + +Test vectors are given below. +### Rationale + +Our proposal should be viewed as a successor to [EIP-1024](https://github.com/topealabi/EIPs/blob/encryption/EIPS/eip-1024.md), which has stagnated. That EIP received some support. It was implemented, and subsequently [deprecated](https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686), by MetaMask; it was also [implemented by Ledger](https://github.com/LedgerHQ/app-ethereum/pull/240). + +The community ultimately declined to ratify that EIP, however, for a few reasons: +- It used the _same_ key both for signing/verifying and for encryption/decryption, which is generally considered bad practice (though cf. [[DLG+11]](https://eprint.iacr.org/2011/615.pdf) and further discussion below); +- That EIP moreover used the same secret key on _two different curves_. + +There is _no security proof_ for a scheme which simultaneously invokes signing on the `secp256k1` curve and encryption on the `ec25519` curve, and where _the same secret key is moreover used in both cases_. Though no attacks are known, it is not desirable to use a scheme which lacks a proof in this way. +We note that the paper [[DLG+11]](https://eprint.iacr.org/2011/615.pdf) studies the reuse of the same key in signing and encryption, but where _the same curve is used in both_ (in the context of EMV payments). That paper finds the joint scheme to be secure in the generic group model. +Though this result provides _some level of_ assurance of security of this joint scheme (where, we stress, _only one_ curve is used), it is at least as secure to use different, pseudorandomly unlinkable keys for signing and encryption. Indeed, we note that if the hash function is modeled as a random oracle, then each decryption key `dk` is completely random, and in particular uncorrelated with its corresponding signing key. + +### Backwards Compatibility +The previous proposal stipulated that encryption and decryption requests contain a `version` string. Our proposal merely adds a case for this string; encryption and decryption requests under the existing scheme will be handled identically. Unfortunately, the previous proposal did _not_ include a version string in `encryptionPublicKey`, and merely returned the `ec25519` public key directly as a string. We thus propose to immediately return the `secp256k1` public key, overwriting the previous behavior. The old behavior can be kept via a legacy method. + +We note that EIP-1024 is _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate. + +### Test Cases + +Starting from the secret _signing key_ + + 0x439047a312c8502d7dd276540e89fe6639d39da1d8466f79be390579d7eaa3b2, + +with Ethereum address `0x72682F2A3c160947696ac3c9CC48d290aa89549c`, the `keccak256`-based KDF described above yields the secret _decryption key_ + + 0xecb4fbc91b48954259469d13d2e69c6fe4b57b73dd9dd277085b2d5e764a4023, + +with `secp256k1` public key + + 0x023e5feced05739d8aad239b037787ba763706fb603e3e92ff0a629e8b4ec2f9be. + +Thus, the request: + +```javascript +request({ + method: 'eth_getEncryptionPublicKey', + params: ["0x72682F2A3c160947696ac3c9CC48d290aa89549c"], +}) +``` +should return: +```javascript +"0x023e5feced05739d8aad239b037787ba763706fb603e3e92ff0a629e8b4ec2f9be" +``` + +Encrypting the message `"My name is Satoshi Buterin"` under the above public key could yield, for example: +```javascript +{ + version: 'secp256k1-sha512kdf-aes256cbc-hmacsha256', + ciphertext: '0x03ab54b1b866c5231787fddc2b4dfe9813b6222646b811a2a395040e24e098ae93e39ceedec5516dbf04dbd7b8f5f5030cde786f6aeed187b1d10965714f8d383c2240b4014809077248ddb66cc8bd86eb815dff0e42b0613bbdd3024532c19d0a', +} +``` +Therefore, the request +```javascript +request({ + method: 'eth_decrypt', + params: [{ + version: 'secp256k1-sha512kdf-aes256cbc-hmacsha256', + ciphertext: '0x03ab54b1b866c5231787fddc2b4dfe9813b6222646b811a2a395040e24e098ae93e39ceedec5516dbf04dbd7b8f5f5030cde786f6aeed187b1d10965714f8d383c2240b4014809077248ddb66cc8bd86eb815dff0e42b0613bbdd3024532c19d0a', + }, "0x72682F2A3c160947696ac3c9CC48d290aa89549c"], +}) +``` +should return the string `"My name is Satoshi Buterin"`. + +### Implementation +We have implemented this functionality in two forks of MetaMask repositories, namely [`firnprotocol/eth-sig-util`](https://github.com/firnprotocol/eth-sig-util/tree/encryption) and [`firnprotocol/eth-simple-keyring`](https://github.com/firnprotocol/eth-simple-keyring/tree/encryption). The vast majority of the code changes reside in the former repository. +Our reference implementation leverages the [`standard-ecies` library](https://github.com/bin-y/standard-ecies) of **@bin-y**, whom we thank. + +## Copyright +Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file From f9506015ea0fdb900600b460e680196252d89cec Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 18:43:10 -0400 Subject: [PATCH 02/19] add category --- EIPS/eip-5605.md | 1 + 1 file changed, 1 insertion(+) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index df65c63098dbb..c51d5d9e2fecc 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -4,6 +4,7 @@ title: New approach for encryption / decryption author: Firn Protocol , Fried L. Trout status: Draft type: Standards Track +category: ERC created: 2022-09-07 --- From 954f5dd3bfdff40cbba2c7bf66ad994abc313dfb Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 18:45:28 -0400 Subject: [PATCH 03/19] add EIP number --- EIPS/eip-5605.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index c51d5d9e2fecc..1fa1d5639ec94 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -1,5 +1,5 @@ --- -eip: +eip: 5605 title: New approach for encryption / decryption author: Firn Protocol , Fried L. Trout status: Draft From 124032b510b0c3f972abe119091dce0dc4fffb1c Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 19:00:39 -0400 Subject: [PATCH 04/19] try to remove all (non-relative) links --- EIPS/eip-5605.md | 46 ++++++++++++++++++++++++++++------------------ 1 file changed, 28 insertions(+), 18 deletions(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index 1fa1d5639ec94..3de077cda1551 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -1,7 +1,7 @@ --- eip: 5605 title: New approach for encryption / decryption -author: Firn Protocol , Fried L. Trout +author: Firn Protocol **@firnprotocol**, Fried L. Trout status: Draft type: Standards Track category: ERC @@ -11,12 +11,12 @@ created: 2022-09-07 ### Abstract -This EIP proposes a new way to encrypt and decrypt using Ethereum keys, which remedies the shortcomings of the now-stagnant [EIP-1024](https://github.com/topealabi/EIPs/blob/encryption/EIPS/eip-1024.md). -This proposal uses separate, unlinkable, pseudorandom keys for signing and encryption; it uses _only_ the `secp256k1` curve, and it uses a standardized version of ECIES (see e.g. [Brown, [SEC 1, § 5.1]](https://www.secg.org/sec1-v2.pdf) and [ANSI X9.63, § 5.8](https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017?source=preview)). +This EIP proposes a new way to encrypt and decrypt using Ethereum keys, which remedies the shortcomings of the now-stagnant EIP-1024 [1]. +This proposal uses separate, unlinkable, pseudorandom keys for signing and encryption; it uses _only_ the `secp256k1` curve, and it uses a standardized version of ECIES (see e.g. Brown [SEC 1, § 5.1] and [ANSI X9.63, § 5.8]). In contrast, EIP-1024 reused secret keys across both signing and encryption, and moreover reused the same secret key across both the `secp256k1` and `ec25519` curves. ### Motivation -Some motivation for introducing encryption to Ethereum has already been discussed in [EIP-1024](https://github.com/topealabi/EIPs/blob/encryption/EIPS/eip-1024.md). +Some motivation for introducing encryption to Ethereum has already been discussed in [EIP-1024]. To that discussion, we add a few further motivating examples. In a certain very common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain). This design pattern allows the dApp/user to bootstrap the security of the _fresh_ secret onto the security of the user's existing HD wallet seed phrase, which the user has already gone through the trouble of safeguarding and storing. This represents a far lower UX burden than forcing the user to store and manage fresh keys directly (which can, and often does, lead to loss of funds). We note that this _exact_ design pattern described above is used today by, e.g., Tornado Cash. @@ -27,20 +27,20 @@ As a separate motivation, we mention the possibility of dApps which facilitate e We describe our approach here; we compare our approach to EIP-1024's in the **Rationale** section below. We use the `secp256k1` curve for both signing and encryption (with different keys, see below). -In the latter case, we use ECIES; specifically, we use a standardized variant, which appears e.g. in [Brown, [SEC 1, § 5.1]](https://www.secg.org/sec1-v2.pdf). +In the latter case, we use ECIES; specifically, we use a standardized variant, which appears e.g. in [SEC 1, § 5.1]. Specifically, we propose the choices: -- the KDF `ANSI-X9.63-KDF`, where the hash function `SHA-512` is used (see [[SEC 1, § 3.6]](https://www.secg.org/sec1-v2.pdf)), -- the HMAC `HMAC–SHA-256–256 with 32 octet or 256 bit keys` (see [[SEC 1, § 3.7]](https://www.secg.org/sec1-v2.pdf)), -- the symmetric encryption scheme `AES–256 in CBC mode` (see [[SEC 1, § 3.8]](https://www.secg.org/sec1-v2.pdf)). +- the KDF `ANSI-X9.63-KDF`, where the hash function `SHA-512` is used (see [SEC 1, § 3.6]), +- the HMAC `HMAC–SHA-256–256 with 32 octet or 256 bit keys` (see [SEC 1, § 3.7]), +- the symmetric encryption scheme `AES–256 in CBC mode` (see [SEC 1, § 3.8]). We finally describe a method to derive encryption secret keys deterministically—but pseudorandomly—from signing keys, in such a way that a natural one-to-one relationship obtains between these keys (this latter property is essential, since it allows Ethereum accounts to be used as handles onto encryption/decryption keys, as both the former and current API interfaces do). -Indeed, we propose that, given a signing private key _sk_ ∈ 𝔽_q—which is naturally represented as a 32-byte big-endian byte string (see [[SEC 1, § 2.3.6–2.3.7]](https://www.secg.org/sec1-v2.pdf)) —the corresponding decryption key _dk_ ∈ 𝔽_q be generated as the 32-byte secret: +Indeed, we propose that, given a signing private key _sk_ ∈ 𝔽_q—which is naturally represented as a 32-byte big-endian byte string (see [SEC 1, § 2.3.6–2.3.7])—the corresponding decryption key _dk_ ∈ 𝔽_q be generated as the 32-byte secret: dk := ANSI-X9.63-KDF(sk), -where moreover the _Ethereum `keccak256`_ hash is used for this KDF. This latter decision is essentially for implementation convenience; indeed, MetaMask's `eth-simple-keyring` already has something close to this functionality [built in](https://github.com/MetaMask/eth-simple-keyring/blob/f8c9105825953e926480e84c001e30ded5e8ebdf/index.js#L185-L192), and it requires only a minimal code change (see also our implementation below). +where moreover the _Ethereum `keccak256`_ hash is used for this KDF. This latter decision is essentially for implementation convenience; indeed, MetaMask's `eth-simple-keyring` already has something close to this functionality built in, and it requires only a minimal code change (see our implementation below). We set _SharedInfo_ to be empty here. -We propose that the binary, _concatenated_ serialization mode for ECIES ciphertexts be used (see [[SEC 1, § 5.1.3, 8.]](https://www.secg.org/sec1-v2.pdf)), both for encryption and decryption, where moreover elliptic curve points are _compressed_. This approach is considerably more space-efficient than the prior approach, which outputted a stringified JSON object (itself containing base64-encoded fields). +We propose that the binary, _concatenated_ serialization mode for ECIES ciphertexts be used (see [SEC 1, § 5.1.3, 8.], both for encryption and decryption, where moreover elliptic curve points are _compressed_. This approach is considerably more space-efficient than the prior approach, which outputted a stringified JSON object (itself containing base64-encoded fields). We moreover propose that binary data be serialized to and from `0x`-prefixed hex strings. We moreover use `0x`-prefixed hex strings to specify private keys and public keys, and represent public keys in compressed form. We represent Ethereum accounts in the usual way (`0x`-prefixed, 20-byte hex strings). Thus, on the request: @@ -76,14 +76,14 @@ where `account` is as above, and `encryptedMessage` is a JSON object with the pr Test vectors are given below. ### Rationale -Our proposal should be viewed as a successor to [EIP-1024](https://github.com/topealabi/EIPs/blob/encryption/EIPS/eip-1024.md), which has stagnated. That EIP received some support. It was implemented, and subsequently [deprecated](https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686), by MetaMask; it was also [implemented by Ledger](https://github.com/LedgerHQ/app-ethereum/pull/240). +Our proposal should be viewed as a successor to [EIP-1024], which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask [MM]; it was also implemented by Ledger [L]. The community ultimately declined to ratify that EIP, however, for a few reasons: -- It used the _same_ key both for signing/verifying and for encryption/decryption, which is generally considered bad practice (though cf. [[DLG+11]](https://eprint.iacr.org/2011/615.pdf) and further discussion below); +- It used the _same_ key both for signing/verifying and for encryption/decryption, which is generally considered bad practice (though cf. [DLG+11] and further discussion below); - That EIP moreover used the same secret key on _two different curves_. There is _no security proof_ for a scheme which simultaneously invokes signing on the `secp256k1` curve and encryption on the `ec25519` curve, and where _the same secret key is moreover used in both cases_. Though no attacks are known, it is not desirable to use a scheme which lacks a proof in this way. -We note that the paper [[DLG+11]](https://eprint.iacr.org/2011/615.pdf) studies the reuse of the same key in signing and encryption, but where _the same curve is used in both_ (in the context of EMV payments). That paper finds the joint scheme to be secure in the generic group model. +We note that the paper [DLG+11] studies the reuse of the same key in signing and encryption, but where _the same curve is used in both_ (in the context of EMV payments). That paper finds the joint scheme to be secure in the generic group model. Though this result provides _some level of_ assurance of security of this joint scheme (where, we stress, _only one_ curve is used), it is at least as secure to use different, pseudorandomly unlinkable keys for signing and encryption. Indeed, we note that if the hash function is modeled as a random oracle, then each decryption key `dk` is completely random, and in particular uncorrelated with its corresponding signing key. ### Backwards Compatibility @@ -138,8 +138,18 @@ request({ should return the string `"My name is Satoshi Buterin"`. ### Implementation -We have implemented this functionality in two forks of MetaMask repositories, namely [`firnprotocol/eth-sig-util`](https://github.com/firnprotocol/eth-sig-util/tree/encryption) and [`firnprotocol/eth-simple-keyring`](https://github.com/firnprotocol/eth-simple-keyring/tree/encryption). The vast majority of the code changes reside in the former repository. -Our reference implementation leverages the [`standard-ecies` library](https://github.com/bin-y/standard-ecies) of **@bin-y**, whom we thank. +We have implemented this functionality in two forks of MetaMask repositories, namely: + - `firnprotocol/eth-sig-util`: https://github.com/firnprotocol/eth-sig-util/tree/encryption, and + - `firnprotocol/eth-simple-keyring`: https://github.com/firnprotocol/eth-simple-keyring/tree/encryption. -## Copyright -Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). \ No newline at end of file +The vast majority of the code changes reside in the former repository. +Our reference implementation leverages the `standard-ecies` library of **@bin-y**, whom we thank; see https://github.com/bin-y/standard-ecies. + +## References + + - [EIP-1024]: PR for now-stagnant EIP-1024. https://github.com/ethereum/EIPs/pull/1098 + - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf + - [ANSI X9.63] ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017?source=preview + - [MM]: MetaMask API Method Deprecation. https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686 + - [L]: `LedgerHQ / app-ethereum` pull request: Add EIP 1024 APDUs. https://github.com/LedgerHQ/app-ethereum/pull/240 + - [DGL+11]: Jean Paul Degabriele, Anja Lehmann, Kenneth G. Paterson, Nigel P. Smart, and Mario Strefler. On the Joint Security of Encryption and Signature in EMV. https://eprint.iacr.org/2011/615.pdf \ No newline at end of file From 982caddf0dbbbd95916ce24258965b12402b7264 Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 19:04:27 -0400 Subject: [PATCH 05/19] more attempts to comply with scan --- EIPS/eip-5605.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index 3de077cda1551..00f8a251a8c81 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -11,12 +11,12 @@ created: 2022-09-07 ### Abstract -This EIP proposes a new way to encrypt and decrypt using Ethereum keys, which remedies the shortcomings of the now-stagnant EIP-1024 [1]. +This EIP proposes a new way to encrypt and decrypt using Ethereum keys, which remedies the shortcomings of the now-stagnant PR #1098. This proposal uses separate, unlinkable, pseudorandom keys for signing and encryption; it uses _only_ the `secp256k1` curve, and it uses a standardized version of ECIES (see e.g. Brown [SEC 1, § 5.1] and [ANSI X9.63, § 5.8]). -In contrast, EIP-1024 reused secret keys across both signing and encryption, and moreover reused the same secret key across both the `secp256k1` and `ec25519` curves. +In contrast, #1098 reused secret keys across both signing and encryption, and moreover reused the same secret key across both the `secp256k1` and `ec25519` curves. ### Motivation -Some motivation for introducing encryption to Ethereum has already been discussed in [EIP-1024]. +Some motivation for introducing encryption to Ethereum has already been discussed in #1098. To that discussion, we add a few further motivating examples. In a certain very common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain). This design pattern allows the dApp/user to bootstrap the security of the _fresh_ secret onto the security of the user's existing HD wallet seed phrase, which the user has already gone through the trouble of safeguarding and storing. This represents a far lower UX burden than forcing the user to store and manage fresh keys directly (which can, and often does, lead to loss of funds). We note that this _exact_ design pattern described above is used today by, e.g., Tornado Cash. @@ -65,7 +65,7 @@ request({ ``` where `account` is as above, and `encryptedMessage` is a JSON object with the properties `version` (an arbitrary string) and `ciphertext` (a `0x`-prefixed, hex-encoded, bytes-like string), the client should operate as follows: - perform a `switch` on the value `encryptedMessage.version`. if it equals: - - `x25519-xsalsa20-poly1305`, then use EIP-1024's specification; + - `x25519-xsalsa20-poly1305`, then use #1098's specification; - `secp256k1-sha512kdf-aes256cbc-hmacsha256`, then proceed as described below; - if it equals neither, throw an error. - find the secret key `sk` corresponding to the Ethereum account `account`, or else return an error if none exists. @@ -76,7 +76,7 @@ where `account` is as above, and `encryptedMessage` is a JSON object with the pr Test vectors are given below. ### Rationale -Our proposal should be viewed as a successor to [EIP-1024], which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask [MM]; it was also implemented by Ledger [L]. +Our proposal should be viewed as a successor to #1098, which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask [MM]; it was also implemented by Ledger [L]. The community ultimately declined to ratify that EIP, however, for a few reasons: - It used the _same_ key both for signing/verifying and for encryption/decryption, which is generally considered bad practice (though cf. [DLG+11] and further discussion below); @@ -147,7 +147,6 @@ Our reference implementation leverages the `standard-ecies` library of **@bin-y* ## References - - [EIP-1024]: PR for now-stagnant EIP-1024. https://github.com/ethereum/EIPs/pull/1098 - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf - [ANSI X9.63] ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017?source=preview - [MM]: MetaMask API Method Deprecation. https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686 From 83466928451fdd702fc043a115bc1029d7f05c61 Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 19:11:43 -0400 Subject: [PATCH 06/19] more adjustments. --- EIPS/eip-5605.md | 28 ++++++++++++++++++---------- 1 file changed, 18 insertions(+), 10 deletions(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index 00f8a251a8c81..1032fdc74c9f7 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -1,7 +1,9 @@ --- eip: 5605 title: New approach for encryption / decryption -author: Firn Protocol **@firnprotocol**, Fried L. Trout +description: defines a specification for encryption and decryption using deterministically derived, pseudorandom keys. +author: Firn Protocol (@firnprotocol), Fried L. Trout +discussions-to: https://discord.gg/x7b75hhZ status: Draft type: Standards Track category: ERC @@ -9,13 +11,13 @@ created: 2022-09-07 --- -### Abstract +## Abstract This EIP proposes a new way to encrypt and decrypt using Ethereum keys, which remedies the shortcomings of the now-stagnant PR #1098. This proposal uses separate, unlinkable, pseudorandom keys for signing and encryption; it uses _only_ the `secp256k1` curve, and it uses a standardized version of ECIES (see e.g. Brown [SEC 1, § 5.1] and [ANSI X9.63, § 5.8]). In contrast, #1098 reused secret keys across both signing and encryption, and moreover reused the same secret key across both the `secp256k1` and `ec25519` curves. -### Motivation +## Motivation Some motivation for introducing encryption to Ethereum has already been discussed in #1098. To that discussion, we add a few further motivating examples. In a certain very common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain). @@ -23,8 +25,8 @@ This design pattern allows the dApp/user to bootstrap the security of the _fresh As a separate motivation, we mention the possibility of dApps which facilitate end-to-end encrypted messaging. -### Specification -We describe our approach here; we compare our approach to EIP-1024's in the **Rationale** section below. +## Specification +We describe our approach here; we compare our approach to #1098's in the **Rationale** section below. We use the `secp256k1` curve for both signing and encryption (with different keys, see below). In the latter case, we use ECIES; specifically, we use a standardized variant, which appears e.g. in [SEC 1, § 5.1]. @@ -74,7 +76,7 @@ where `account` is as above, and `encryptedMessage` is a JSON object with the pr - decode the resulting binary plaintext as a `utf-8` string, and return it. Test vectors are given below. -### Rationale +## Rationale Our proposal should be viewed as a successor to #1098, which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask [MM]; it was also implemented by Ledger [L]. @@ -86,10 +88,10 @@ There is _no security proof_ for a scheme which simultaneously invokes signing o We note that the paper [DLG+11] studies the reuse of the same key in signing and encryption, but where _the same curve is used in both_ (in the context of EMV payments). That paper finds the joint scheme to be secure in the generic group model. Though this result provides _some level of_ assurance of security of this joint scheme (where, we stress, _only one_ curve is used), it is at least as secure to use different, pseudorandomly unlinkable keys for signing and encryption. Indeed, we note that if the hash function is modeled as a random oracle, then each decryption key `dk` is completely random, and in particular uncorrelated with its corresponding signing key. -### Backwards Compatibility +## Backwards Compatibility The previous proposal stipulated that encryption and decryption requests contain a `version` string. Our proposal merely adds a case for this string; encryption and decryption requests under the existing scheme will be handled identically. Unfortunately, the previous proposal did _not_ include a version string in `encryptionPublicKey`, and merely returned the `ec25519` public key directly as a string. We thus propose to immediately return the `secp256k1` public key, overwriting the previous behavior. The old behavior can be kept via a legacy method. -We note that EIP-1024 is _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate. +We note that #1098 is _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate. ### Test Cases @@ -145,10 +147,16 @@ We have implemented this functionality in two forks of MetaMask repositories, na The vast majority of the code changes reside in the former repository. Our reference implementation leverages the `standard-ecies` library of **@bin-y**, whom we thank; see https://github.com/bin-y/standard-ecies. -## References +## Security Considerations +Our proposal uses heavily standardized algorithms and follows all best practices. + +## Copyright +Copyright and related rights waived via [CC0](../LICENSE.md). + +References: - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf - [ANSI X9.63] ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017?source=preview - [MM]: MetaMask API Method Deprecation. https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686 - - [L]: `LedgerHQ / app-ethereum` pull request: Add EIP 1024 APDUs. https://github.com/LedgerHQ/app-ethereum/pull/240 + - [L]: `LedgerHQ / app-ethereum` pull request: Add `EIP 1024` APDUs. https://github.com/LedgerHQ/app-ethereum/pull/240 - [DGL+11]: Jean Paul Degabriele, Anja Lehmann, Kenneth G. Paterson, Nigel P. Smart, and Mario Strefler. On the Joint Security of Encryption and Signature in EMV. https://eprint.iacr.org/2011/615.pdf \ No newline at end of file From f4fefc3513ee9c120b529ccb2d700807266c23b8 Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 19:20:15 -0400 Subject: [PATCH 07/19] make links verbatim; try to satisfy HTML Proofer --- EIPS/eip-5605.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index 1032fdc74c9f7..d4fc55955916f 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -157,6 +157,6 @@ References: - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf - [ANSI X9.63] ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017?source=preview - - [MM]: MetaMask API Method Deprecation. https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686 - - [L]: `LedgerHQ / app-ethereum` pull request: Add `EIP 1024` APDUs. https://github.com/LedgerHQ/app-ethereum/pull/240 + - [MM]: MetaMask API Method Deprecation. `https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686` + - [L]: `LedgerHQ / app-ethereum` pull request: Add `EIP 1024` APDUs. `https://github.com/LedgerHQ/app-ethereum/pull/240` - [DGL+11]: Jean Paul Degabriele, Anja Lehmann, Kenneth G. Paterson, Nigel P. Smart, and Mario Strefler. On the Joint Security of Encryption and Signature in EMV. https://eprint.iacr.org/2011/615.pdf \ No newline at end of file From a1bb2ffdec5601f2cbf9689d3b4cd6d88afa1ff0 Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 19:22:43 -0400 Subject: [PATCH 08/19] create ethereum magicians page --- EIPS/eip-5605.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index d4fc55955916f..51a3c29d0dedd 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -3,7 +3,7 @@ eip: 5605 title: New approach for encryption / decryption description: defines a specification for encryption and decryption using deterministically derived, pseudorandom keys. author: Firn Protocol (@firnprotocol), Fried L. Trout -discussions-to: https://discord.gg/x7b75hhZ +discussions-to: https://ethereum-magicians.org/t/eip-5605-encryption-and-decryption/10761 status: Draft type: Standards Track category: ERC From 50c8b0cd25c1e7c482adeac8ef843be71e38117c Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 19:28:03 -0400 Subject: [PATCH 09/19] remove offending links --- EIPS/eip-5605.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index 51a3c29d0dedd..92e2bd56a2910 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -157,6 +157,6 @@ References: - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf - [ANSI X9.63] ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017?source=preview - - [MM]: MetaMask API Method Deprecation. `https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686` - - [L]: `LedgerHQ / app-ethereum` pull request: Add `EIP 1024` APDUs. `https://github.com/LedgerHQ/app-ethereum/pull/240` + - [MM]: MetaMask API Method Deprecation. + - [L]: `LedgerHQ / app-ethereum` pull request #240: Add `EIP 1024` APDUs. - [DGL+11]: Jean Paul Degabriele, Anja Lehmann, Kenneth G. Paterson, Nigel P. Smart, and Mario Strefler. On the Joint Security of Encryption and Signature in EMV. https://eprint.iacr.org/2011/615.pdf \ No newline at end of file From cafc4b6136ffe8c7758b0976de5c9cea3b869f3a Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 20:21:05 -0400 Subject: [PATCH 10/19] another attempt at HTML proofer --- EIPS/eip-5605.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index 92e2bd56a2910..c0a8eb0df3393 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -156,7 +156,7 @@ Copyright and related rights waived via [CC0](../LICENSE.md). References: - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf - - [ANSI X9.63] ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017?source=preview - - [MM]: MetaMask API Method Deprecation. - - [L]: `LedgerHQ / app-ethereum` pull request #240: Add `EIP 1024` APDUs. + - [MM]: MetaMask API Method Deprecation. https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686 + - [ANSI X9.63] ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017 + - [L]: `LedgerHQ / app-ethereum` pull request 240: Add `EIP 1024` APDUs. https://github.com/LedgerHQ/app-ethereum/pull/240 - [DGL+11]: Jean Paul Degabriele, Anja Lehmann, Kenneth G. Paterson, Nigel P. Smart, and Mario Strefler. On the Joint Security of Encryption and Signature in EMV. https://eprint.iacr.org/2011/615.pdf \ No newline at end of file From 2a1c1bd39188680265f01c6b6d617fe0e44a4aa6 Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 20:42:21 -0400 Subject: [PATCH 11/19] some kind of bug with HTML proofer trying again --- EIPS/eip-5605.md | 23 ++++++++++++----------- 1 file changed, 12 insertions(+), 11 deletions(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index c0a8eb0df3393..40c6333eab40a 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -13,20 +13,20 @@ created: 2022-09-07 ## Abstract -This EIP proposes a new way to encrypt and decrypt using Ethereum keys, which remedies the shortcomings of the now-stagnant PR #1098. +This EIP proposes a new way to encrypt and decrypt using Ethereum keys, which remedies the shortcomings of the now-stagnant PR [#1098]. This proposal uses separate, unlinkable, pseudorandom keys for signing and encryption; it uses _only_ the `secp256k1` curve, and it uses a standardized version of ECIES (see e.g. Brown [SEC 1, § 5.1] and [ANSI X9.63, § 5.8]). -In contrast, #1098 reused secret keys across both signing and encryption, and moreover reused the same secret key across both the `secp256k1` and `ec25519` curves. +In contrast, [#1098] reused secret keys across both signing and encryption, and moreover reused the same secret key across both the `secp256k1` and `ec25519` curves. ## Motivation -Some motivation for introducing encryption to Ethereum has already been discussed in #1098. +Some motivation for introducing encryption to Ethereum has already been discussed in [#1098]. -To that discussion, we add a few further motivating examples. In a certain very common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain). +To that discussion, we add a few further motivating examples. In a certain common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain). This design pattern allows the dApp/user to bootstrap the security of the _fresh_ secret onto the security of the user's existing HD wallet seed phrase, which the user has already gone through the trouble of safeguarding and storing. This represents a far lower UX burden than forcing the user to store and manage fresh keys directly (which can, and often does, lead to loss of funds). We note that this _exact_ design pattern described above is used today by, e.g., Tornado Cash. As a separate motivation, we mention the possibility of dApps which facilitate end-to-end encrypted messaging. ## Specification -We describe our approach here; we compare our approach to #1098's in the **Rationale** section below. +We describe our approach here; we compare our approach to [#1098]'s in the **Rationale** section below. We use the `secp256k1` curve for both signing and encryption (with different keys, see below). In the latter case, we use ECIES; specifically, we use a standardized variant, which appears e.g. in [SEC 1, § 5.1]. @@ -67,7 +67,7 @@ request({ ``` where `account` is as above, and `encryptedMessage` is a JSON object with the properties `version` (an arbitrary string) and `ciphertext` (a `0x`-prefixed, hex-encoded, bytes-like string), the client should operate as follows: - perform a `switch` on the value `encryptedMessage.version`. if it equals: - - `x25519-xsalsa20-poly1305`, then use #1098's specification; + - `x25519-xsalsa20-poly1305`, then use [#1098]'s specification; - `secp256k1-sha512kdf-aes256cbc-hmacsha256`, then proceed as described below; - if it equals neither, throw an error. - find the secret key `sk` corresponding to the Ethereum account `account`, or else return an error if none exists. @@ -78,7 +78,7 @@ where `account` is as above, and `encryptedMessage` is a JSON object with the pr Test vectors are given below. ## Rationale -Our proposal should be viewed as a successor to #1098, which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask [MM]; it was also implemented by Ledger [L]. +Our proposal should be viewed as a successor to [#1098], which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask [MM]; it was also implemented by Ledger [L]. The community ultimately declined to ratify that EIP, however, for a few reasons: - It used the _same_ key both for signing/verifying and for encryption/decryption, which is generally considered bad practice (though cf. [DLG+11] and further discussion below); @@ -91,7 +91,7 @@ Though this result provides _some level of_ assurance of security of this joint ## Backwards Compatibility The previous proposal stipulated that encryption and decryption requests contain a `version` string. Our proposal merely adds a case for this string; encryption and decryption requests under the existing scheme will be handled identically. Unfortunately, the previous proposal did _not_ include a version string in `encryptionPublicKey`, and merely returned the `ec25519` public key directly as a string. We thus propose to immediately return the `secp256k1` public key, overwriting the previous behavior. The old behavior can be kept via a legacy method. -We note that #1098 is _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate. +We note that [#1098] is _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate. ### Test Cases @@ -155,8 +155,9 @@ Copyright and related rights waived via [CC0](../LICENSE.md). References: + - [#1098]: Pull Request: "Add web3.eth.encrypt and web3.eth.decrypt functions to JSON-RPC". https://github.com/ethereum/EIPs/pull/1098 - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf - - [MM]: MetaMask API Method Deprecation. https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686 - - [ANSI X9.63] ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017 - - [L]: `LedgerHQ / app-ethereum` pull request 240: Add `EIP 1024` APDUs. https://github.com/LedgerHQ/app-ethereum/pull/240 + - [MM API]: MetaMask API Method Deprecation. https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686 + - [ANSI X9.63]: ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017 + - [L#240]: `LedgerHQ / app-ethereum` pull request 240: Add `EIP 1024` APDUs. https://github.com/LedgerHQ/app-ethereum/pull/240 - [DGL+11]: Jean Paul Degabriele, Anja Lehmann, Kenneth G. Paterson, Nigel P. Smart, and Mario Strefler. On the Joint Security of Encryption and Signature in EMV. https://eprint.iacr.org/2011/615.pdf \ No newline at end of file From 0f964331cb82b3b6604f39b390dbf9ae7ba96503 Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 20:45:01 -0400 Subject: [PATCH 12/19] minor stuff --- EIPS/eip-5605.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index 40c6333eab40a..178c818f701ba 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -78,7 +78,7 @@ where `account` is as above, and `encryptedMessage` is a JSON object with the pr Test vectors are given below. ## Rationale -Our proposal should be viewed as a successor to [#1098], which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask [MM]; it was also implemented by Ledger [L]. +Our proposal should be viewed as a successor to [#1098], which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask [MM API]; it was also implemented by Ledger [L#240]. The community ultimately declined to ratify that EIP, however, for a few reasons: - It used the _same_ key both for signing/verifying and for encryption/decryption, which is generally considered bad practice (though cf. [DLG+11] and further discussion below); @@ -97,15 +97,15 @@ We note that [#1098] is _not_ (to our knowledge) implemented in a non-deprecated Starting from the secret _signing key_ - 0x439047a312c8502d7dd276540e89fe6639d39da1d8466f79be390579d7eaa3b2, + 0x439047a312c8502d7dd276540e89fe6639d39da1d8466f79be390579d7eaa3b2 with Ethereum address `0x72682F2A3c160947696ac3c9CC48d290aa89549c`, the `keccak256`-based KDF described above yields the secret _decryption key_ - 0xecb4fbc91b48954259469d13d2e69c6fe4b57b73dd9dd277085b2d5e764a4023, + 0xecb4fbc91b48954259469d13d2e69c6fe4b57b73dd9dd277085b2d5e764a4023 with `secp256k1` public key - 0x023e5feced05739d8aad239b037787ba763706fb603e3e92ff0a629e8b4ec2f9be. + 0x023e5feced05739d8aad239b037787ba763706fb603e3e92ff0a629e8b4ec2f9be Thus, the request: @@ -153,7 +153,7 @@ Our proposal uses heavily standardized algorithms and follows all best practices ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). -References: +###References: - [#1098]: Pull Request: "Add web3.eth.encrypt and web3.eth.decrypt functions to JSON-RPC". https://github.com/ethereum/EIPs/pull/1098 - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf From 603a59adc4a2e757f9762de0b48b5d9121fde7dc Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 8 Sep 2022 20:51:21 -0400 Subject: [PATCH 13/19] just remove the two references can't figure out how to satisfy HTML proofer --- EIPS/eip-5605.md | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5605.md index 178c818f701ba..c4eab5f13d931 100644 --- a/EIPS/eip-5605.md +++ b/EIPS/eip-5605.md @@ -78,7 +78,7 @@ where `account` is as above, and `encryptedMessage` is a JSON object with the pr Test vectors are given below. ## Rationale -Our proposal should be viewed as a successor to [#1098], which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask [MM API]; it was also implemented by Ledger [L#240]. +Our proposal should be viewed as a successor to [#1098], which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask; it was also implemented by Ledger (see links below). The community ultimately declined to ratify that EIP, however, for a few reasons: - It used the _same_ key both for signing/verifying and for encryption/decryption, which is generally considered bad practice (though cf. [DLG+11] and further discussion below); @@ -157,7 +157,5 @@ Copyright and related rights waived via [CC0](../LICENSE.md). - [#1098]: Pull Request: "Add web3.eth.encrypt and web3.eth.decrypt functions to JSON-RPC". https://github.com/ethereum/EIPs/pull/1098 - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf - - [MM API]: MetaMask API Method Deprecation. https://medium.com/metamask/metamask-api-method-deprecation-2b0564a84686 - [ANSI X9.63]: ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017 - - [L#240]: `LedgerHQ / app-ethereum` pull request 240: Add `EIP 1024` APDUs. https://github.com/LedgerHQ/app-ethereum/pull/240 - [DGL+11]: Jean Paul Degabriele, Anja Lehmann, Kenneth G. Paterson, Nigel P. Smart, and Mario Strefler. On the Joint Security of Encryption and Signature in EMV. https://eprint.iacr.org/2011/615.pdf \ No newline at end of file From 0dc82d47e80a8e3e96dcb971a73c3e9ee2ea65c8 Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Fri, 9 Sep 2022 08:35:03 -0400 Subject: [PATCH 14/19] rename file to match PR number --- EIPS/{eip-5605.md => eip-5630.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename EIPS/{eip-5605.md => eip-5630.md} (100%) diff --git a/EIPS/eip-5605.md b/EIPS/eip-5630.md similarity index 100% rename from EIPS/eip-5605.md rename to EIPS/eip-5630.md From e7cfd688b622781ab20c0243253f9d330dc350fc Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Fri, 9 Sep 2022 08:36:58 -0400 Subject: [PATCH 15/19] also adjust table --- EIPS/eip-5630.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/EIPS/eip-5630.md b/EIPS/eip-5630.md index c4eab5f13d931..12c91829cc18c 100644 --- a/EIPS/eip-5630.md +++ b/EIPS/eip-5630.md @@ -1,9 +1,9 @@ --- -eip: 5605 +eip: 5630 title: New approach for encryption / decryption description: defines a specification for encryption and decryption using deterministically derived, pseudorandom keys. author: Firn Protocol (@firnprotocol), Fried L. Trout -discussions-to: https://ethereum-magicians.org/t/eip-5605-encryption-and-decryption/10761 +discussions-to: https://ethereum-magicians.org/t/eip-5630-encryption-and-decryption/10761 status: Draft type: Standards Track category: ERC From 9a2e457745dfa1653255d7d6a1c9e3d9551b8f8b Mon Sep 17 00:00:00 2001 From: Pandapip1 <45835846+Pandapip1@users.noreply.github.com> Date: Thu, 15 Sep 2022 09:46:44 -0400 Subject: [PATCH 16/19] Update eip-5630.md --- EIPS/eip-5630.md | 66 +++++++++++++++++++++++------------------------- 1 file changed, 32 insertions(+), 34 deletions(-) diff --git a/EIPS/eip-5630.md b/EIPS/eip-5630.md index 12c91829cc18c..32d2dc5c99a14 100644 --- a/EIPS/eip-5630.md +++ b/EIPS/eip-5630.md @@ -13,45 +13,50 @@ created: 2022-09-07 ## Abstract -This EIP proposes a new way to encrypt and decrypt using Ethereum keys, which remedies the shortcomings of the now-stagnant PR [#1098]. -This proposal uses separate, unlinkable, pseudorandom keys for signing and encryption; it uses _only_ the `secp256k1` curve, and it uses a standardized version of ECIES (see e.g. Brown [SEC 1, § 5.1] and [ANSI X9.63, § 5.8]). -In contrast, [#1098] reused secret keys across both signing and encryption, and moreover reused the same secret key across both the `secp256k1` and `ec25519` curves. +This EIP proposes a new way to encrypt and decrypt using Ethereum keys. This EIP uses separate, unlinkable, pseudorandom keys for signing and encryption; it uses _only_ the `secp256k1` curve, and it uses a standardized version of ECIES. In contrast, other EIPs reused secret keys across both signing and encryption, and moreover reused the same secret key across both the `secp256k1` and `ec25519` curves. ## Motivation -Some motivation for introducing encryption to Ethereum has already been discussed in [#1098]. To that discussion, we add a few further motivating examples. In a certain common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain). + This design pattern allows the dApp/user to bootstrap the security of the _fresh_ secret onto the security of the user's existing HD wallet seed phrase, which the user has already gone through the trouble of safeguarding and storing. This represents a far lower UX burden than forcing the user to store and manage fresh keys directly (which can, and often does, lead to loss of funds). We note that this _exact_ design pattern described above is used today by, e.g., Tornado Cash. As a separate motivation, we mention the possibility of dApps which facilitate end-to-end encrypted messaging. ## Specification -We describe our approach here; we compare our approach to [#1098]'s in the **Rationale** section below. + +We describe our approach here; we compare our approach to other EIPs in the **Rationale** section below. We use the `secp256k1` curve for both signing and encryption (with different keys, see below). -In the latter case, we use ECIES; specifically, we use a standardized variant, which appears e.g. in [SEC 1, § 5.1]. +In the latter case, we use ECIES; specifically, we use a standardized variant. Specifically, we propose the choices: -- the KDF `ANSI-X9.63-KDF`, where the hash function `SHA-512` is used (see [SEC 1, § 3.6]), -- the HMAC `HMAC–SHA-256–256 with 32 octet or 256 bit keys` (see [SEC 1, § 3.7]), -- the symmetric encryption scheme `AES–256 in CBC mode` (see [SEC 1, § 3.8]). + +- the KDF `ANSI-X9.63-KDF`, where the hash function `SHA-512` is used, +- the HMAC `HMAC–SHA-256–256 with 32 octet or 256 bit keys`, +- the symmetric encryption scheme `AES–256 in CBC mode`. We finally describe a method to derive encryption secret keys deterministically—but pseudorandomly—from signing keys, in such a way that a natural one-to-one relationship obtains between these keys (this latter property is essential, since it allows Ethereum accounts to be used as handles onto encryption/decryption keys, as both the former and current API interfaces do). -Indeed, we propose that, given a signing private key _sk_ ∈ 𝔽_q—which is naturally represented as a 32-byte big-endian byte string (see [SEC 1, § 2.3.6–2.3.7])—the corresponding decryption key _dk_ ∈ 𝔽_q be generated as the 32-byte secret: +Indeed, we propose that, given a signing private key _sk_ ∈ 𝔽_q—which is naturally represented as a 32-byte big-endian byte string—the corresponding decryption key _dk_ ∈ 𝔽_q be generated as the 32-byte secret: +```solidity dk := ANSI-X9.63-KDF(sk), +``` + where moreover the _Ethereum `keccak256`_ hash is used for this KDF. This latter decision is essentially for implementation convenience; indeed, MetaMask's `eth-simple-keyring` already has something close to this functionality built in, and it requires only a minimal code change (see our implementation below). We set _SharedInfo_ to be empty here. -We propose that the binary, _concatenated_ serialization mode for ECIES ciphertexts be used (see [SEC 1, § 5.1.3, 8.], both for encryption and decryption, where moreover elliptic curve points are _compressed_. This approach is considerably more space-efficient than the prior approach, which outputted a stringified JSON object (itself containing base64-encoded fields). +We propose that the binary, _concatenated_ serialization mode for ECIES ciphertexts be used (both for encryption and decryption, where moreover elliptic curve points are _compressed_. This approach is considerably more space-efficient than the prior approach, which outputted a stringified JSON object (itself containing base64-encoded fields). We moreover propose that binary data be serialized to and from `0x`-prefixed hex strings. We moreover use `0x`-prefixed hex strings to specify private keys and public keys, and represent public keys in compressed form. We represent Ethereum accounts in the usual way (`0x`-prefixed, 20-byte hex strings). Thus, on the request: + ```javascript request({ method: 'eth_getEncryptionPublicKey', params: [account], }) ``` + where `account` is a standard 20-byte, `0x`-prefixed, hex-encoded Ethereum account, the client should operate as follows: - find the secret signing key `sk` corresponding to the Ethereum account `account`, or else return an error if none exists. - compute the 32-byte secret `dk := ANSI-X9.63-KDF(sk)`, where the `keccak256` hash is used in the KDF. @@ -59,12 +64,14 @@ where `account` is a standard 20-byte, `0x`-prefixed, hex-encoded Ethereum accou - return this public key in compressed, `0x`-prefixed, hex-encoded form. On the request + ```javascript request({ method: 'eth_decrypt', params: [encryptedMessage, account], }) ``` + where `account` is as above, and `encryptedMessage` is a JSON object with the properties `version` (an arbitrary string) and `ciphertext` (a `0x`-prefixed, hex-encoded, bytes-like string), the client should operate as follows: - perform a `switch` on the value `encryptedMessage.version`. if it equals: - `x25519-xsalsa20-poly1305`, then use [#1098]'s specification; @@ -78,34 +85,34 @@ where `account` is as above, and `encryptedMessage` is a JSON object with the pr Test vectors are given below. ## Rationale -Our proposal should be viewed as a successor to [#1098], which has stagnated. That EIP received some support. It was implemented, and subsequently deprecated, by MetaMask; it was also implemented by Ledger (see links below). - -The community ultimately declined to ratify that EIP, however, for a few reasons: -- It used the _same_ key both for signing/verifying and for encryption/decryption, which is generally considered bad practice (though cf. [DLG+11] and further discussion below); -- That EIP moreover used the same secret key on _two different curves_. - There is _no security proof_ for a scheme which simultaneously invokes signing on the `secp256k1` curve and encryption on the `ec25519` curve, and where _the same secret key is moreover used in both cases_. Though no attacks are known, it is not desirable to use a scheme which lacks a proof in this way. -We note that the paper [DLG+11] studies the reuse of the same key in signing and encryption, but where _the same curve is used in both_ (in the context of EMV payments). That paper finds the joint scheme to be secure in the generic group model. +Some papers study the reuse of the same key in signing and encryption, but where _the same curve is used in both_ (in the context of EMV payments). That paper finds the joint scheme to be secure in the generic group model. Though this result provides _some level of_ assurance of security of this joint scheme (where, we stress, _only one_ curve is used), it is at least as secure to use different, pseudorandomly unlinkable keys for signing and encryption. Indeed, we note that if the hash function is modeled as a random oracle, then each decryption key `dk` is completely random, and in particular uncorrelated with its corresponding signing key. ## Backwards Compatibility The previous proposal stipulated that encryption and decryption requests contain a `version` string. Our proposal merely adds a case for this string; encryption and decryption requests under the existing scheme will be handled identically. Unfortunately, the previous proposal did _not_ include a version string in `encryptionPublicKey`, and merely returned the `ec25519` public key directly as a string. We thus propose to immediately return the `secp256k1` public key, overwriting the previous behavior. The old behavior can be kept via a legacy method. -We note that [#1098] is _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate. +We note that other EIPs are _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate. ### Test Cases Starting from the secret _signing key_ +``` 0x439047a312c8502d7dd276540e89fe6639d39da1d8466f79be390579d7eaa3b2 +``` with Ethereum address `0x72682F2A3c160947696ac3c9CC48d290aa89549c`, the `keccak256`-based KDF described above yields the secret _decryption key_ +``` 0xecb4fbc91b48954259469d13d2e69c6fe4b57b73dd9dd277085b2d5e764a4023 +``` with `secp256k1` public key +``` 0x023e5feced05739d8aad239b037787ba763706fb603e3e92ff0a629e8b4ec2f9be +``` Thus, the request: @@ -115,19 +122,24 @@ request({ params: ["0x72682F2A3c160947696ac3c9CC48d290aa89549c"], }) ``` + should return: + ```javascript "0x023e5feced05739d8aad239b037787ba763706fb603e3e92ff0a629e8b4ec2f9be" ``` Encrypting the message `"My name is Satoshi Buterin"` under the above public key could yield, for example: + ```javascript { version: 'secp256k1-sha512kdf-aes256cbc-hmacsha256', ciphertext: '0x03ab54b1b866c5231787fddc2b4dfe9813b6222646b811a2a395040e24e098ae93e39ceedec5516dbf04dbd7b8f5f5030cde786f6aeed187b1d10965714f8d383c2240b4014809077248ddb66cc8bd86eb815dff0e42b0613bbdd3024532c19d0a', } ``` + Therefore, the request + ```javascript request({ method: 'eth_decrypt', @@ -137,25 +149,11 @@ request({ }, "0x72682F2A3c160947696ac3c9CC48d290aa89549c"], }) ``` -should return the string `"My name is Satoshi Buterin"`. - -### Implementation -We have implemented this functionality in two forks of MetaMask repositories, namely: - - `firnprotocol/eth-sig-util`: https://github.com/firnprotocol/eth-sig-util/tree/encryption, and - - `firnprotocol/eth-simple-keyring`: https://github.com/firnprotocol/eth-simple-keyring/tree/encryption. -The vast majority of the code changes reside in the former repository. -Our reference implementation leverages the `standard-ecies` library of **@bin-y**, whom we thank; see https://github.com/bin-y/standard-ecies. +should return the string `"My name is Satoshi Buterin"`. ## Security Considerations Our proposal uses heavily standardized algorithms and follows all best practices. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md). - -###References: - - - [#1098]: Pull Request: "Add web3.eth.encrypt and web3.eth.decrypt functions to JSON-RPC". https://github.com/ethereum/EIPs/pull/1098 - - [SEC 1]: SEC 1: Elliptic Curve Cryptography. Daniel R. L. Brown. https://www.secg.org/sec1-v2.pdf - - [ANSI X9.63]: ANSI X9.63-2011 (R2017): Public Key Cryptography For The Financial Services Industry. https://webstore.ansi.org/Standards/ASCX9/ANSIX9632011R2017 - - [DGL+11]: Jean Paul Degabriele, Anja Lehmann, Kenneth G. Paterson, Nigel P. Smart, and Mario Strefler. On the Joint Security of Encryption and Signature in EMV. https://eprint.iacr.org/2011/615.pdf \ No newline at end of file From 950489f684830fac86e4cd077e2d78c2bea501bc Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 15 Sep 2022 10:31:06 -0400 Subject: [PATCH 17/19] remove spurious parenthesis --- EIPS/eip-5630.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5630.md b/EIPS/eip-5630.md index 32d2dc5c99a14..e9f1c1883a66e 100644 --- a/EIPS/eip-5630.md +++ b/EIPS/eip-5630.md @@ -45,7 +45,7 @@ Indeed, we propose that, given a signing private key _sk_ ∈ 𝔽_q—which is where moreover the _Ethereum `keccak256`_ hash is used for this KDF. This latter decision is essentially for implementation convenience; indeed, MetaMask's `eth-simple-keyring` already has something close to this functionality built in, and it requires only a minimal code change (see our implementation below). We set _SharedInfo_ to be empty here. -We propose that the binary, _concatenated_ serialization mode for ECIES ciphertexts be used (both for encryption and decryption, where moreover elliptic curve points are _compressed_. This approach is considerably more space-efficient than the prior approach, which outputted a stringified JSON object (itself containing base64-encoded fields). +We propose that the binary, _concatenated_ serialization mode for ECIES ciphertexts be used, both for encryption and decryption, where moreover elliptic curve points are _compressed_. This approach is considerably more space-efficient than the prior approach, which outputted a stringified JSON object (itself containing base64-encoded fields). We moreover propose that binary data be serialized to and from `0x`-prefixed hex strings. We moreover use `0x`-prefixed hex strings to specify private keys and public keys, and represent public keys in compressed form. We represent Ethereum accounts in the usual way (`0x`-prefixed, 20-byte hex strings). Thus, on the request: From fe8504f4023f257cc0a830d10b86900c36505f8b Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 15 Sep 2022 10:36:21 -0400 Subject: [PATCH 18/19] grammar --- EIPS/eip-5630.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/EIPS/eip-5630.md b/EIPS/eip-5630.md index e9f1c1883a66e..c5266e0510318 100644 --- a/EIPS/eip-5630.md +++ b/EIPS/eip-5630.md @@ -86,7 +86,7 @@ Test vectors are given below. ## Rationale There is _no security proof_ for a scheme which simultaneously invokes signing on the `secp256k1` curve and encryption on the `ec25519` curve, and where _the same secret key is moreover used in both cases_. Though no attacks are known, it is not desirable to use a scheme which lacks a proof in this way. -Some papers study the reuse of the same key in signing and encryption, but where _the same curve is used in both_ (in the context of EMV payments). That paper finds the joint scheme to be secure in the generic group model. +Certain papers have studied the reuse of the same key in signing and encryption, but where _the same curve is used in both_ (e.g., in the context of EMV payments). Those papers have found the joint scheme to be secure in the generic group model. Though this result provides _some level of_ assurance of security of this joint scheme (where, we stress, _only one_ curve is used), it is at least as secure to use different, pseudorandomly unlinkable keys for signing and encryption. Indeed, we note that if the hash function is modeled as a random oracle, then each decryption key `dk` is completely random, and in particular uncorrelated with its corresponding signing key. ## Backwards Compatibility From 5fb65cf1a4a592249cc9095522541b8796c7a6a8 Mon Sep 17 00:00:00 2001 From: Firn Protocol Date: Thu, 15 Sep 2022 11:06:56 -0400 Subject: [PATCH 19/19] a few more grammar changes post-edits --- EIPS/eip-5630.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/EIPS/eip-5630.md b/EIPS/eip-5630.md index c5266e0510318..445bd02506116 100644 --- a/EIPS/eip-5630.md +++ b/EIPS/eip-5630.md @@ -17,7 +17,7 @@ This EIP proposes a new way to encrypt and decrypt using Ethereum keys. This EIP ## Motivation -To that discussion, we add a few further motivating examples. In a certain common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain). +We discuss a few motivating examples. In a certain common design pattern, a dApp generates a fresh secret on behalf of a user. It is of interest if, instead of forcing this user to independently store, safeguard, and back up this latter secret, the dApp may instead encrypt this secret to a public key which the user controls—and whose secret key, crucially, can be derived deterministically from the user's HD wallet hierarchy—and then post the resulting ciphertext to secure storage (e.g., on-chain). This design pattern allows the dApp/user to bootstrap the security of the _fresh_ secret onto the security of the user's existing HD wallet seed phrase, which the user has already gone through the trouble of safeguarding and storing. This represents a far lower UX burden than forcing the user to store and manage fresh keys directly (which can, and often does, lead to loss of funds). We note that this _exact_ design pattern described above is used today by, e.g., Tornado Cash. @@ -74,7 +74,7 @@ request({ where `account` is as above, and `encryptedMessage` is a JSON object with the properties `version` (an arbitrary string) and `ciphertext` (a `0x`-prefixed, hex-encoded, bytes-like string), the client should operate as follows: - perform a `switch` on the value `encryptedMessage.version`. if it equals: - - `x25519-xsalsa20-poly1305`, then use [#1098]'s specification; + - `x25519-xsalsa20-poly1305`, then use #1098's specification; - `secp256k1-sha512kdf-aes256cbc-hmacsha256`, then proceed as described below; - if it equals neither, throw an error. - find the secret key `sk` corresponding to the Ethereum account `account`, or else return an error if none exists. @@ -92,7 +92,7 @@ Though this result provides _some level of_ assurance of security of this joint ## Backwards Compatibility The previous proposal stipulated that encryption and decryption requests contain a `version` string. Our proposal merely adds a case for this string; encryption and decryption requests under the existing scheme will be handled identically. Unfortunately, the previous proposal did _not_ include a version string in `encryptionPublicKey`, and merely returned the `ec25519` public key directly as a string. We thus propose to immediately return the `secp256k1` public key, overwriting the previous behavior. The old behavior can be kept via a legacy method. -We note that other EIPs are _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate. +We note that the previous EIP is _not_ (to our knowledge) implemented in a non-deprecated manner in _any_ production code today, and the EIP stagnated. We thus have a lot of flexibility here; we only need enough backwards compatibility to allow dApps to migrate. ### Test Cases