Why Does FHEVM Need to Verify Ciphertexts If Encryption Is Already Done Client-Side?

Zama Protocol FHEVM
1

Hi, all:

If encryption is already performed on the client, why does FHEVM still need to verify the submitted ciphertexts?
What exactly is the purpose of this verification — to confirm the ciphertext corresponds to a valid plaintext, or to ensure some structural or security properties?
What risks or failures could arise if this verification step were omitted?

1 Like
2

Hi,

I was wondering the same thing this morning, I found some answers here (can’t publish links :/) in the docs:

  • solidity-guides > getting-started > quick-start-tutorial > turn_it_into_fhevm > replace-increment-uint32-value-with-the-fhevm-version-increment-externaleuint32-value
  • protocol > solidity-guides > smart-contract > inputs

So the verification checks that: the handle points to a ciphertext “owned” by the sender and that this handle is meant to be used by this specific contract.
As far as I understand, this avoids eavesdroppers to re-use a handle used on another contract/by another user for malicious intents.

Again, from what I understand, the verification is done off-chain and is signed by the coprocessors. Only the signature verification is checked on-chain requiring trust in coprocessors.

I’m also learning, could someone confirm/correct this?

3

Hey

We need to check that a user A knows the plaintext that he submits to the blockchain for security: if we were not checking, then user A might take the ciphertext from user B, and claim it was his (A’s) ciphertext. Then, A might eg add 0, and ask for the decryption of the result. Finally, it would be a way for A to decrypt ciphertext of B.

This is related to ACL, access control list, Access Control List | Solidity Guides | Protocol

Cheers

4

Hey

Yes, the input proof check is done by the coprocessors. There is a consensus between the (5) coprocessors to avoid one of them misbehave.

Cheers

5

When user A requests to decrypt ciphertext C generated by user B, the ACL check will fail immediately due to insufficient permissions, so the actual decryption flow is never reached. Even if a “+0” operation is attempted, it will be blocked at the ACL check inside the FHEExecutor.

6

When user A requests to decrypt ciphertext C generated by user B

But if there was no ZK proof, A would claim that the ciphertext C is actually a fresh ciphertext of him (ie, a ciphertext of A), so the ACL would let him do anything from here, including decrypting. This is why we have to check that A knows the plaintext corresponding to a ciphertext when he submits something in the system

1 Like
7

Thank you, I’ve got it.

1 Like