Excellent! Good to see that we are moving on.
BTW, what do you think about the situation that cipher text might become very long and too long for some wallet to handle? My suggestion is for the wallet to only derive the symmetric key (and IV etc) necessary to decrypt the cipher.
I mean writing to the data field. This could be a contract call or simply raw hex with an identifier followed by the public key, Iām open to suggestions.
Also, not implying that reading a transaction requires gas, simply stating that among the many ways to transmit metadata about a public key, this is probably the cheapest way to do it.
Thinking about this more since our last, the answer might be a new smart contract type that manages decentralized PKI. What you have now is succinct and enforces separation of concerns.
yes @Weiji, this is an intriguing suggestion. thank you. sorry for not getting to this earlier.
i think in the vast majority of cases, the caller and callee of eth_decrypt will be on the same machine, or separated by a USB-C in the case of standard hardware wallets. in this kind of case, bandwidth / communication throughput will not be not a problem. regarding buffer overflows, i am simply not versed in enough in how hardware wallets work to know whether this is a problem. maybe we can find some experts to weigh in. likewise, as far as optical scanning, this is very new to me. it could be a problem, but seems like an unusual case.
overall though, i like this idea, since it really only gives us more flexibility. in particular, it allows the decryptor (and of course also the encryptor) to choose an arbitrary variant of ECIES, without re-implementing or changing whatās baked into the hardware wallet (this is very slow and difficult to do). instead, the hardware wallet only does the sensitive operation, and the rest is handled outside.
the only downside i see is that it makes it more complicated for implementers. it also is not compatible with the encryptTo smart contract method newly proposed, since that method requires the entire encryption to be computed, not just the ECDH.
so at this point it seems to me like a tradeoff between simplicity, on the one hand, and flexibility + bandwidth improvement on the other. i am still not sure where i stand exactly. we could also do both! but i also prefer to keep the EIP as simple as possible. let me think about this for a bit. thanks again for the suggestion.
I am fully in support of the general case that doesnāt hardcode the ECIES variant, just because I prefer flexibility wherever it can be offered. I nonetheless accept that this is my opinion and that othersā may differ.
Note that if you choose this path, you should include validation of the elliptic curve in the spec, as there are attacks possible if it is not performed.
good to know; thanks for your feedback. I will let this bake for some more time and then make a decision. (but leaning towards agreeing with you and @Weiji right now.)
right; i expect that i will use compressed representation in any case, so thereās not as much to validate. but indeed, i will definitely include validation that the 33-byte datum passed in actually represents a valid compressed point (essentially, you just need to verify that the first byte is 0x02 or 0x03, and that the remaining 32 bytes yield a quadratic residue under the RHS of the Weierstrass equation). edit but note that this validation is essentially just a sanity check; wrong curve / twist attacks are not possible in the compressed setting. indeed, if the (compressed) point is not valid, then it becomes literally nonsensical, and doesnāt make sense to proceed; itās not something that could silently go undetected and lead to an attack.
i have gone ahead and made the update to the EIP. thus, now, the wallet will only do ECDH, and the rest of ECIES is chosen / carried out by the application-level implementer. (this is actually much closer to how GPG does it, btw.)
big thanks to @Weiji for the idea (maybe we should add you as an author? 
) i stipulate that all checks during deserialization MUST be carried out by the wallet; cc. @Pandapip1.
Oh that is very nice and sweet. Please do, use Weiji Guo (@weijiguo). Or do I need to open a PR?
done. welcome friend!
intereting: Ronin Bridge Exploiter communicating with Euler Finance Exploiter using ECIES encryption on-chain. see https://twitter.com/TheDEFIac/status/1638243255941840896/photo/1
this is what we are trying to standardize. edit no endorsement of either party.
hey love the proposal could you share a link to poc or the pull request unable to find it.
hi. keep in mind this is an EIP; it is only a spec; it is not a code change or a PR. it is up to wallet maintainers to implement it. with that said, there was previously a reference implementation, but it has become out-of-date (see above changes to EIP) and was removed. all of the basic functionality described in this EIP can be implemented in a few lines of code using nodeās crypto library.
Over the past few months, I have conducted thorough research on encryption and decryption using Ethereum key pairs. My findings suggest that Hybrid Public Key Encryption (HPKE) is a more suitable solution for this purpose when compared to Elliptic Curve Integrated Encryption Scheme (ECIES), which is now considered outdated. I recommend adopting HPKE, as explained in this Cloudflare blog post.
Although the Internet Engineering Task Force (IETF) has not incorporated the secp256k1 curve into the HPKE cipher suite, the overall system is well-constructed and robust. For example, the hpke-js library effectively implements DHKEM (secp256k1, HKDF-SHA256), demonstrating the strength and adaptability of HPKE.
I was planning to create a similar EIP but not limited to encryption and decryption functionalities two years ago when hundreds of millions of dollars were lost in De-Fi hacks. My intention is to create an on-chain announcement system, that, any party can send a public/encrypted message to any wallet address since wallet is the most accessible and direct way to contact with users on any blockchain, especially when an attack is ongoing and projects need to notify their users to move their assets directly through a most native way, wallet, instead of through an email or a shout-out on twitter. We at Mask Network have been using secp256k1 to enable users to encrypt their messages and posts on social medias since 2019 and I believe we could definitely contribute with our past experience handling both encrypted DM and group messages. However, what Iād like to propose in addition to this is that we need to turn this into an announcement scheme with a standard message payload spec, including fields like sender, ephemeral_pub, signed_ephemeral_pub, hmac, nonce, message, etc. This will help standardize the effort any wallet need to take to integrate this kind of on-chain messages.
hi, thanks for your contribution.
not sure i fully understand. keep in mind that our ciphertext already includes ephemeral_pub and hmac, by definition of ECIES. as for message, that doesnāt make sense, since itās encrypted. signed_ephemeral_pub and nonce i donāt understand.
in any case, i am definitely open to specāing out more details around how messages should be sent onchain. in my opinion, the most urgently needed thing is some kind of onchain inbox infrastructure, some kind of smart contract to store received messages.
before changing the spec though, i think our first task should be to gain momentum and buy-in from wallet devs. that is our most urgent goal at this stage of the EIP i think, since we risk becoming stagnant if we donāt kick off some momentum among wallets.
signed_ephemeral_pub is how you verify the relationship between this ephemeral key and the message sender and nonce is just a factor to prove freshness of the message in a security perspective. Sorry about the confusion here since I didnāt want to include too much into the reply.
However, I donāt actually think these messages need to be stored in a smart contract. Instead, a standardized payload format is needed to be defined and we can easily include them in the data field of each transaction to minimize the gas cost. This could also make wallet implementation easier since all they need to do is to monitor oneās wallet(which is already being deployed) and decode the message for users to decrypt with their private key. Not sure about your opinion on this.
hmm. if we donāt use a smart contract, weād need some sort of addressing scheme in order to make the messages receivable.
as for thisāi just assumed that authenticity would come from the sender posting the ciphertext to the onchain inbox using his Ethereum account. so authenticity would come for free. but yes, barring this, you could sign the ephemeral pubkey (or the whole thing).
right, if we donāt use smart contracts, then yesāthough again, we have the problem of delivering messages to their intended recipient. how do you plan to address that?
either way, as mentioned above, i think we need to synchronize with wallet devs to get them onboard, before we start making further design decisions.
I believe that Request Network is a potential use case for EIP-5630.
Details: Iām a dApp developer at Request Network. Request Network stores encrypted payment requests (often referred to as āInvoicesā) in IPFS using the āhybridā style of encryption mentioned in previous comments. The request data is encrypted using a one-time-use symmetric key and then copies of the symmetric key are encrypted using asymmetric keys, one for each stakeholder of the request. Request Network provides a client library that can be run in the dApp frontend. Weāre looking into using EIP-1024 but would prefer to use EIP-5630 once an implementation exists.
hi. sounds like a great use-case. thanks for reaching out.
keep in mind, EIP-1024 (really, PR #1024, since it was never merged) has been implemented only by MetaMask, and is deprecated. so i donāt think it would be wise to deploy a production app based on it.
we are planning to begin a bit of wallet outreach soon. any help on this front would also be appreciated, if you have connections with wallets.
though thereās no public ref implementation right now, itās almost trivial to implement using Nodeās crypto library. if you want help with this i can.
I working with a smaller wallet dev on this proposal. PM me for more details and for collaboration. (https://settle0x.com/)
Hi @yisiliu @firnprotocol, Iām drafting EIP-7017, a notifications protocol that standardizes one-to-one and one-to-many messages. Naturally, one-to-one messages must be encrypted and EIP-5630 seems like the way to go.
Receivers should not have to do any dedicated action on-chain like posting their public key on a ENS, as it would be a massive barrier for the protocol. Iām sure other usecases for this EIP feel the same way. Is it possible to get the key from a transaction signed by the receiver in the past?
If so, I would like to collaborate on an MVP to showcase both EIP-5630 and EIP-7017 so as to get wallets to implement them.