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?