Add web3.eth.encrypt method for RPC & web3

[danfinlay]

Update: Parity Implemented

This EIP now recommends that the Parity methods encryptMessage and decryptMessage be added to the personal namespace.

https://github.com/paritytech/parity/wiki/JSONRPC-parity-module#parity_encryptmessage

Below is the original post, which is less refined. Below that is the full discussion.

Specification

Option 1: Add a new method, encrypt(account, data, [cb]), and decrypt(account, data, [cb]) or something else, that allows a user to encrypt & decrypt arbitrary lengths of data with an account's private key, as well as clarify the documentation of eth.sign.

Option 2: Clarify to current implementations that eth.sign should work for arbitrary lengths of data, not only with sha3 hashes, as well as add an encrypt method.

Rationale

Currently there is a web3.eth.sign method that is described as a general signature method in the wiki, but in practice, implementations have made it a de-facto signHash method.

There is still a valuable place for a method to sign and encrypt arbitrary data with an account's private key (or an arbitrary public key). For example, using an account's private key can be used to encrypt private data that is stored in public, like personal data. A recent casual example would be saving wallet nicknames in a secure way, but obviously more serious examples abound, including potentially medical data.

To reconcile the current lack of a general purpose data signing method, I recommend we either endorse a new method or change the old. Since applications exist and already rely on the current eth.sign, that's probably an inconsiderate option, so I personally think a new method is in order.

[aakilfernandes]

@FlySwatter actually just deleted the comment bc i realized you need a json rpc method, and that is eip fitting

[coder5876]

It's not really clear to me how encrypt(account, data, [cb]) should be defined. From the input it looks like we should be treating the private key corresponding to account as a symmetric encryption key and doing symmetric encryption with that key (i.e. no recipient public keys in the input parameters etc). If this is the case then we need to specify the encryption algorithm (AES? Which mode? XSalsa20? something else?) and it seems that we would be moving away quite a bit from what we would expect the RPC spec to support.

If we are doing asymmetric (public key) encryption/decryption (through something like ECIES), then the inputs to the encrypt function should be a public key or a list of public keys that we want to have as targets of the encryption, and we need to define a spec for the structure of the encrypted blob including nonces or IVs etc. Again it seems to be a lot of work that fall outside the realm of expected supported functionality of the RPC spec.

[danfinlay]

I think the method I’m really looking for is better defined as decrypt(account_number, data, algorithm, [cb]).

That’s because I think there’s a valuable place in letting a user decrypt data of an arbitrary size using their private key, unlike the current eth.sign method which only supports signing hashes.

The reason I think this is suitable for the RPC spec is because web3 currently provides a variety of methods which assume the user has a private key. Since web3 is already responsible for exposing an interface to a key pair, and we’re already doing the work of getting users to manage a key pair, it seems very strange that we limit that key to a single function.

To demonstrate the usefulness of this feature, try to answer this question: If a Ðapp wanted to use ether accounts to allow encrypted communication, what would the flow be?

Encrypting to a public key can actually be done fine outside the scope of web3, so this proposal probably needs some revision, but once a message is received, the user needs a method to decrypt an arbitrary blob with an arbitrary algorithm.

Currently, there’s no method to formally request this via the web3 interface, so the Ðapp would have to provide some copy-paste text, and trust the user to extract their private key manually, and feed it into an encryption algorithm themselves.

That’s a lot of work to utilize an encryption key that is held in every wallet. Since web3 has already assumed the job of integrating user-controlled encryption into the browser, I can’t see a better place to finish the feature.

I do understand that these operations aren’t explicitly required for the bare Ethereum protocol itself, but I don’t think web3’s job is to merely support Ethereum, it should aspire to support the next wave of distributed applications, and that includes public key cryptography.

[coder5876]

Yes, a decrypt function would be doable I think. But you would still need to define a corresponding encrypt function outside of web3, and make sure you can extract the public key in order for people to encrypt to you.

It's a tricky problem design wise for sure. Currently I'm leaning towards letting various dapps and/or whisper-like protocols handle the key management themselves and using your main Ethereum keys to "provision" these encryption keys (by signing the public encryption keys) and associate them to your identity through a registry or similar. But I do agree that there is value in using your keystore for encryption keys as well.

[wighawag]

Any update on this ?

the ability to encrypt and decrypt data for the user is a must.

The ability to sign arbitrary data with personal_sign has already be proven useful but whenever we want to share private data across device we would require encryption/decryption.

Note that parity is already implementing something along these line : https://github.com/paritytech/parity/wiki/JSONRPC-parity-module#parity_encryptmessage

it require the ability to get a public key out of an address though:
openethereum/parity-ethereum#5869

It would be great to have it standardised

[danfinlay]

I'd be happy to implement the feature as specified by Parity, but as eth_encryptMessage and eth_decryptMessage instead of using the parity prefix. I don't understand why Parity made this method platform-specific. Maybe @gavofyork would like to comment.

[danfinlay]

One reason might be that the decrypt method requires using accounts, so this means it requires a signer, which may not be the appropriate responsibility of the eth_ prefix. Maybe then this belongs on the personal_ API?

Also, since you don't need access to private keys to encrypt, it might make just as much sense to keep it on a separate utility.

Really what you need is a personal_decrypt function, and maybe nothing else, so you could rely on utility libraries like eth-sig-util for encrypting to public keys.

[wighawag]

encrypting would still require to get the public key out of the ethereum address

maybe a personal_getPublicKey ?