[Feature] Decryption Function & Public Key

[ajkagy]

A variety of use cases can take advantage of users possessing self custody cryptographic keys within blockchain wallets, but in order for these use cases to be realized, wallets need to implement decryption functions that will decrypt messages that were encrypted with the user's public key.

Solution

Function: decrypt
Decrypts a string of data that was encrypted with the user's public key. fails if invalid.
Params:

1. EncryptedMessage - the encrypted message to decrypt
2. XRPL address - The address of the XRPL account that can decrypt the message.

Returns: decrypted message

Function: getEncryptionPublicKey
Requests that the user share their public encryption key. Returns a public encryption key, or rejects if the user denies the request.

Params:

1. XRPL address

Returns: Public Key

[WietseWind]

@N3TC4T Thoughts? This could be implemented as a Pseudo Transaction, and has two options:

1. Encrypt / Decrypt something for own use, encrypt now, decrypt later
2. Shared Key (Diffie Hellman), where another pubkey can be provided, so ext. pubkey + own private key, encrypt + decrypt

Especially 2. would be interesting, as the counterparty owning the account with key to pubkey provided, can decrypt with signer's pubkey and own private key. Which would mean two accounts (or a user & a platform) can securely exchange data only visible for the two of them.

@ajkagy Do your use cases require blob/binary, or would it be plain text to be encrypted/decrypted?

I'm asking because I'm not in favour of enabling this for random binary. I'd say it should be plain text (UTF-8) so we can at least show users a readable version of what they are about to encrypt / what they did decrypt.

[ajkagy]

@ajkagy Do your use cases require blob/binary, or would it be plain text to be encrypted/decrypted?

I'm asking because I'm not in favour of enabling this for random binary. I'd say it should be plain text (UTF-8) so we can at least show users a readable version of what they are about to encrypt / what they did decrypt.

I think it should be plain text (UTF-8), at least from use cases that I've seen. I'm not really aware of any use cases that would require blob/binary.

in regards to 2, this would be perfect and even better for P2P operations and wallet<>wallet messages, which is one of the use cases I had in mind originally with encrypt/decrypt. Essentially I wanted to generate a separate set of keys for messaging, where the new generated privkey would be encrypted/decrypted by the wallet keys.