Your latter statement is correct! By Degabriele et al., it is secure to use the same key for ECDSA and ECIES in the generic group model. Given this, we decided to take a slightly more conservative and hygienic approach by deriving a separate enc/dec keypair from the signing key. Degrabriele et al. proves that this could be done using the same keypair, but we leverage a KDF to additionally establish distinct decryption vs signing keys, just as a low-cost, conservative measure.
1 Like
This is awesome!
Currently I’m developing an SBT protocol for managing credentials and memberships. We have an extension in our contract for managing the visibility of a token, so people can make their SBT private. To protect the owner’s privacy we also need to make sure that the off-chain data gets encrypted. I’ve thought about something like PGP encryption for emails.
Now if this gets supported by wallets it will be easier to encrypt/decrypt the metadata!
BTW: We have submitted our EIP draft and if you guys are interested please check.
awesome! i’ll take a look; glad to have you interested in this EIP and on board.
1 Like
Speaking as a maintainer of MetaMask, we want to support an encryption / decryption feature, and are grateful for the work everyone here is putting into creating a new standard.
I want to note that we have strong reservations about supporting encryption and decryption using secp256k1 due the concerns outlined here: blog/secp256k1_twist_attacks.md at master · christianlundkvist/blog · GitHub
In my understanding, secp256k1 is rarely if ever used for encryption / decryption. The only justification I’ve seen for it in this thread is that it’s convenient for the Ethereum ecosystem, and that strikes me as a weak argument. Using e.g. curve25519 as @chrislundkvist suggests in the above blog post would be our preference, and doing so would make us more likely to implement this standard, not less.
1 Like
hi @rekmarks. many thanks for the response and good to hear from you.
i want to first be clear about a few conceptual matters before we proceed. as i understand, this is an attack on ECDH, and ECIES is completely unaffected. indeed, it can only take place when the victim exponentiates an attacker-supplied point by a sensitive scalar, and then sends the result back to the attacker. but this pattern only happens in ECDH, and never in ECIES. since, in ECIES, the only sensitive Diffie–Hellman operation happens during decryption, but in this case the victim—who would be the decryptor—will never send the resulting DH point back to the attacker (and will only use it to attempt an AES decryption). keep in mind that ECIES has an asymmetry which ECDH doesn’t.
(there is a further Diffie–Hellman operation which happens during encryption; indeed, the encryptor exponentiates the decryptor’s public key by an ephemeral scalar. here too the attack would be useless, since there’s nothing to learn—the exponent here is ephemeral, not persistent.)
separately—even in the ECDH case—this sort of attack is only possible when using uncompressed points (we use compressed), and is moreover only possible when the implementation fails to check whether a point is on the curve.
before we discuss further merits of using secp256k1 vs. curve25519 i want to make sure we are in agreement on the above first? look forward to continuing the discussion.
It’s worth jumping in here to highlight what I’m thinking with regards to a storage solution further here.
I’m in favor of an inbox style approach where it’s more like wallet_store(message: JSON) call. It’s still encrypted message, and by starting with storage we can build messaging primitives upwards from this design that lead to an async messaging protocol able to be built on top. E.g. think of encrypted email with an inbox style endpoint that can be managed by the wallet.
Wayne Change from Spruce does a good job describing the concept briefly in this talk: Ethereum's Identity Layer - Impact of Ethereum Presentation
Spitballing here as to what this might look like wallet_store() could just expose something like a decentralized web node. This way we’re able to reuse a lot of the design.
With that said, I’ll note that we’ve got a second dApp here interested in using this API, so my theory may be invalid that this is too low level to be useful. So let me add some questions if we were going to take this encrypt/decrypt API approach and run with it. (and then work on storage separately)
- How would we expose to the user the encrypt API for the message flowing from the user to the dApp?
- What use cases would we expect to address here and more importantly what use cases are we leaving on the table by picking this design? The more specific we can be here the better.
- Do we leave message migration (even between wallets maintained by the same company such as Metamask mobile and metamask extension) out of scope?
1 Like
btw, while I think this is technically true, note that P256 is often used for encryption / decryption, and the P256 and secp256k1 curves are extremely similar in spirit. In particular, both are Weierstrass curves, and are equally vulnerable to this “attack” (though as argued above, it appears the attack doesn’t apply to ECIES). in particular, ECIES with P256 is supported by many hardware enclaves, e.g. iOS’s.
@firnprotocol thanks for proposing. Very interesting EIP. I look forward to it!
I am thinking this encryption and decryption can also be leveraged by EIP-5437: Security Contact Interface
2 Likes
fascinating. i agree completely!
in fact, your proposal looks almost exactly like the “inbox” idea we discussed above. see this quote e.g.:
thus I think our proposals are very much complementary and glad to see you have done this 
(the only difference appears to be using GPG w/ RSA vs. ECIES. though the former is somewhat more standard, the latter has smaller key sizes and ciphertexts. but it seems that your proposal is ultimately agnostic to the encryption scheme used.)
really appreciate you sharing, and look forward to continuing the discussion.
EIP-5630 + EIP-5437 sounds cost prohibitive for a generic inbox style messaging system. It also sounds like it would discourage reporting bugs. If this is done it’s going to be limited in scope of usage to only high value messages. Gas fees already can touch $5+ for a transaction on L1 at peek capacity and the incentives don’t align for security researchers to report vulnerabilities if there’s an additional cost to submit a bug report.
This seems like it would be recreating the economics of email spam protection mechanisms that were never widely used. I don’t think this would be useful. Can someone explain the usefulness of this from the security researcher’s perspective that would justify why this is better than a H1 bug bounty program?
I am interested in this EIP and curious to help push it forward in whatever form. I think there are a large variety of use cases.
I am most interested in building an encrypted filesystem primitive. The file is a well established pattern and will help bring the EVM up a level of abstraction to more users. This primitive alone enables many new use cases.
A filesystem/namespace could generally looks like Upspin to start. In terms of cryptography and access control Upspin chooses to implement something very similar to what is suggested by @SamWilsn. That is: using asymmetric keys for encrypting a symmetric passcode which then encrypts a file. This method could reasonably be used to share files and do access control.
I’ve built a proto-version of this using the deprecated eth_encrypt and eth_decrypt provided by MetaMask, and it would be nice to have an EIP which is well supported across many wallet implementations. I have no preference for curves, so whatever seems most cryptographically secure seems to make sense. I think it seems like this would be curve25519 instead of secp256k1.
On top of such a filesystem primitive many applications could be built. Messaging. Encrypted File Sharing. Encrypted Group Photo Albums. Encrypted GPS data. Helping to give people better ownership and control over their data using ETH address as an identifier. This may not ultimately be enough to solve UX problems, but may get us closer to revealing what is possible through mainstream adoption of asymmetric public key cryptography by the way of a decentralized system at the user level.
@rekmarks in terms of supporting a new standard from MetaMask’s perspective, what would be the key functionality or difference from the original EIP-1024’s specification you’d be looking for?
Also curious from @kdenhartog, what would be required for adoption of a fairly generic encryption/decryption EIP? What is left for something like this to have approval? Choice of curve? More specific methodology? Anything else?
1 Like
hi @cjpais, thanks for the message, and glad to have you on board! i absolutely agree with the applications you proposed.
regarding the matter of curves, i have already weighed in above: see the message beginning
as well as the subsequent one. as I’ve already “made my case” on this front, I will defer from further comment at this time, and let the community come to an agreement on this one (though if further input is wanted from me, I’m happy to give it).
my best stab at answering this question would be, “avoid the reuse of the same secret key in two different curves”. thus, something like our use of a KDF is perhaps what’s wanted. (others have taken issue with the fact that we additionally use secp256k1 for the encryption curve, though, as I’ve made clear above, I emphatically maintain that this is not a security concern.) happy to advocate for this with you, as well as discuss any questions you have.
1 Like
I’m very excited to see a follow up to EIP-1024. I’m one of the developers of Moonfish, basically a GPG-like solution for email using Ethereum keys.
If the decision to use a single curve was made to make the life of wallet developers easy, I have to agree with @kdenhartog. Using two curves shouldn’t be an issue. I’d suggest to use proven models, unless there is a good reason not to (there might be one that I missed, feel free to correct me).
As I understand the proposal, the intention is to encrypt the message itself asymmetrically. While this works, I do see two possible issues:
-
I am not sure if it’s still an issue on modern devices, but asymmetric encryption is slower than symmetric encryption. If you want to scale the solution for use with large attachments or files (as mentioned in one comment), you might run into performance issues on low-end devices. Then again, maybe it’s not an issue, but I would certainly benchmark it.
-
The current proposal doesn’t seem to support multiple recipients, a common scenario in messaging and email.
Have you considered using the GPG model where the message itself is encrypted with a one-time symmetrical session key, and the session key itself is encrypted with the recipient’s public key? This would scale for multiple recipients.
Another things worth considering is adding metadata to the standard, such as chainID and the public keys/addresses of the sender and all recipients to simplify replying to an encrypted message.
I’d like to point out the implications of this to a MPC/TSS controlled wallet. It seems to me very difficult if not infeasible to derive a new key pair if the underlying secret key is controlled by multiple parties through some TSS scheme, like GG18/GG20 or some other similar ones.
Also, if we keep using the same key pair, then the public key is available if the account had signed any messages on-chain: ECDSA allows public key recovery from signature. This will save lots of troubles of key discovery.
Also as Ethereum accounts are migrating to Account Abstraction / ERC-4337 contracts, maybe it makes sense to allow contracts to have an API to expose its public key for encryption purposes.
this is an interesting point about key discovery. i am actually perfectly open to using literally the same secp256k1 keypair for both signing and decryption. as remarked above, this scheme is proven secure in the generic group model, and is probably the best from a simplicitly standpoint. cc. @kdenhartog.
you’re absolutely right. FWIW, it is possible to do HKDF through MPC, or, at least, 2PC, and even to do it relatively efficiently (say, using garbled circuits), but it is very difficult implementation-wise. so I agree that this would be essentially prohibitive.
Also curious from @kdenhartog, what would be required for adoption of a fairly generic encryption/decryption EIP? What is left for something like this to have approval? Choice of curve? More specific methodology? Anything else?
First off, support should be added for both encryption and decryption in a bilateral direction. It seems everyone here wants to focus on the bikeshed of which cryptographic primitives to use, without considering there’s no widely deployed solution for a dApp to have a public key so we’ll still be stuck with every request to the dApp being sent over TLS, but all the responses are encrypted to the ethereum account.
This is effectively like building TLS where the browser only sends HTTP requests and the server only responds with HTTPS responses.
let’s keep the tone respectful, please.
Happy to edit my comment since it’s tone has come off in a way other than intended. Which parts would you like changed?