How it Works
The idea behind reencryption is that the user generates on the client-side an ephemeral private/public keypair. The user will then ask the covalidator to decrypt an on-chain handle, and immediately reencrypt the plaintext using the user’s generated public key. This way, only the user can decrypt the reencrypted ciphertext using the ephemeral private key. A sequence diagram of the reencryption flow can be found in the Decryption Mechanisms page.Access Control
Access control is of particular importance in the reencrypt flow. A reencrypt request is valid only if the two following conditions are met:- the user requesting a reencryption must have access to the handle. This on-chain validation prevents other people seeing your own private data, and vice-versa.
- the user requesting a reencryption must sign an EIP-712 message over the ephemeral public key they generated, using the same address that has access to the handle. This ensures that it’s indeed the user that requested a reencryption to that ephemeral public key, and not some malicious actor.
Requesting a Reencryption
A reencryption does not require any on-chain transaction. On the contract side, we simply require that the handle is publicly readable. For example, for a confidential token contract, the mapping of user address to confidential balance can be madepublic
.
Once the handle to be reencrypted is retrieved on the client side, we can use the JS SDK’s reencryptor
to request a reencryption. The SDK will perform all the low-level steps, such as generating an ephemeral keypair and signing the EIP-712 message, and will return the plaintext value.