Parity-ethereum: Ability to encrypt by providing an address only

[wighawag]

Currently the parity json api allow to encrypt arbitrary data with arbitrary public key.

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

This is useful but in most case dapp only have access to the ethereum address.

It would be nice to either

• provide a api to convert an address into a public key
• or allow to pass an ethereum address to the encrypt method (that would convert the address into the public key internaly)

We could actually provide both option

[5chdn]

Unless I'm mistaken, un-hashing the public address is not possible. However, exposing an API which allows to use a Parity account to encrypt a message to, should certainly work.

[tomusdrw]

It's should also be possible for accounts that have sent at least one transaction, we can recover the public key from the signature.

[debris]

I will close this issue, cause I think that we'll never implement it. There are few technical/design difficulties which makes this rpc method not possible to implement or useless.

• public key can't be derived from address, therefore we can't create a method like parity_encryptMessage which accepts an address instead of a public key
• we could add an additional argument to this method, which allows user to decrypt local account, fetch a private key from there, derive public key and encrypt the message. But the whole point of encrypting the message is to allow some third party who owns the private key to read the message. So this just useless method
• we could make a lot of variations of previous point which do not require a password from user, but all of these variations are useless as long as user is encrypting the message using his own account
• we could also create a database column and store address -> public entries there, but it's just unnecessary bloat and with the current size of the state, it's not racional

[wighawag]

Thank @debris for commenting. the reasoning make sense.

I'd like to mention that the original use case that lead me to post the issue in the first place was about encrypting the user own data for later use, hence would not require the database overhead and the solution you mention in 1 and 2 could be used.

So could we reconsider this issue on that ground or maybe create a new one that explicit focus on the ability for a user to encrypt data for later use without requiring authentication?

Think of a dapp that decrypt data on launch (asking user permission), then as the user use the dapp, the dapp continously encrypt the changes without requiring permission (so the user can quit the app at any time). Then upon reloading the dapp, the user can decrypt (asking permission again) and start use the dapp with the perviously saved data.

We could either have a modified version parity_encryptMessage that will give an error when asking to encrypt data for an account it has no private key

Alternatively and probably better, we could have a method getPublicKey that would return the user public key.

Regarding the need to ask permission for when the account nonce is zero (no transaction have yet revealed the account's public key to the world) I would argue that permission should not be required at all as it is implicit that account used in the context of dapp will generate transaction at some point and thus are inherently hot wallet.