Handle encryption with an Ethereum private key
Manipulating private keys must be done with care. Losing them can lead to a loss of data, privacy or non-repudiation safety!
A request can be encrypted in order to make its details private to selected stakeholders. In this guide, we won't explain how encryption is managed under the hood. We will mention encryption or decryption of requests with payers and payees keys. Although in practice, we will use an intermediate symmetric key. See more details on github.
The transaction layer manages the encryption, see more details on the Request Protocol section.
To manipulate encrypted requests you need a Decryption Provider, e.g.:
Ethereum Private Key Decryption Provider (provided by Request for illustration), using the private keys directly. This provider manipulates private keys clearly, which is not entirely secure. Please consider creating your own; see below.
You can also create your decryption provider following the specification. Feel free to contact us for any help or any idea about it: Join our Discord here
Create an encrypted request
Ethereum Private Key Decryption Provider (see on github)
Then you can create an encrypted request:
Note: You must give at least one encryption key you can decrypt with the decryption provider. Otherwise, an error will be triggered after the creation.
Get invoice information from its request ID
Let's step back for a second: the requester sent a request that he encrypted with the payer's public key, as well as with his own, to retrieve it later. This is an essential and typical example, but a request can be encrypted with many keys to give access to its status and details.
If the decryption provider knows a private key matching one of the keys used at the creation, it can decrypt it. Like a clear request you can get it from its request id.
Accepting/canceling an invoice information
Like a clear request, you can update it if the decryption provider is instantiated with a matching private key.
Last updated