eip: 1024
title: Add web3.eth.encrypt and web3.eth.decrypt functions
author: Tope Alabi <alabitemitope@gmail.com>
status: Draft
type: Interface Track
created: 2018-05-14
Abstract
This EIP proposes a cross-client method for requesting encryption/decryption. This method will include a version parameter, so that different encryption methods can be added under the same name. Nacl is a cryptographically complete and well audited library that works well for this by implementers are free to choos…

In this thread I’d like to open the discussion to issues related to the user experience of encryption and decryption in web3 browsers.

A few questions I have, with my current opinions stated after them:

Should users be prompted before their encryption public key is exposed to the dapp via web3.eth.getEncryptionPublicKey?

I think especially with improved “explicit sign in” that this could be unnecessary, and associated keys could be revealed with a single “sign in” request.

Should we prompt users to encrypt?

This probably isn’t necessary, since encryption doesn’t require their private key material at all, could be performed without a web3 browser.

Eventually if/when we add a “sign and encrypt” method, we can prompt the user in one place there.

Should we prompt users to decrypt and download a file?

I don’t think this is necessary, since it does not expose the decrypted data to anyone but the user’s own hard disk.

Should we return decrypted data to the requesting Ðapp?

This is the behavior that I think would require a prompt and user authorization.

For the sake of keeping decryption-heavy dapps practical and usable, we probably want to introduce a batch requestPersistentUsageOfDecryptionKeyForAccount( account ) method.

The Dapp should provide a user a way of revoking this decryption method if it can be extended.

On that note I posted a new topic on UX ring to bring discussion on these proposals, see here

One thing I did not mention and that you touch upon here is “encryption and the use of public key”.

So as to answer your point :1. Should users be prompted before their encryption public key?

We could either

consider the public key as “already public” in the context of the wallet, or

we provide an api for encryption that do not reveal the public key.

In regard to 1), this is not too far fetched for most web3 browser as it is expected of the user to sign messages or transactions at some point. If not, are we going to explain to them that their public key will be public after their first transactions?

I think unless, the user is knowledgeable of what is happening, it would scare most user and most would simply accept such warning.

At the same time, 2) allow us to simply bypass the need for revealing the public key.

2. Should we prompt users to encrypt?
As you mentioned, this would be unnecessary if they have access to the public key

4. Should we return decrypted data to the requesting Ðapp?
As you understood from the article if the application encode the origin(s) allowed to decrypt the web3 browser could check the origin of the document attempting to decrypt and make sure they match before revealing the decrypted data.
This would also allow to safeguard from other application asking to decrypt data without the web3 browser having context to explain to the user where that data came from.

It’s stil draft. In particular it is not specified how the user confirmation would work. My original use case is for signing, but I’d like it to be general enough to solve all future needs for cryptography, including what EIP2¹⁰: Encrypt/Decrypt covers. My hope is to make it so good that it can be merged with EIP1024 into one proposal that covers all our wallet crypto needs.