Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: size-efficient list-based ciphertext inputs #120

Merged
merged 1 commit into from
Jun 18, 2024

Conversation

dartdart26
Copy link
Collaborator

@dartdart26 dartdart26 commented Jun 17, 2024

Add support for list-based ciphertext inputs. Two types are supported:

  • CompactFheUint160List
  • CompactFheUint2048List

No other input types are supported. Instead, the fhevmjs library encodes any type other than the FheUint2048 type as FheUint160. In fhevm-go during ciphertext verification, we cast it homomorphically to the requested data type. FheUint2048 values are expanded as is, without any casts.

The API of the verifyCiphertext precompile changes such that now it accepts two inputs (through TFHE.asEuintXX() library function in fhevm):

  • bytes32 Handle
  • serialized compact FHE list

Handle format changes and is no longer the hash of the expanded ciphertext. Instead, input handles have the following format:

  • byte 0 to 28: first 29 bytes of keccak256(keccak256(serialized compact FHE list) || index)
  • byte 29: index in the serialized compact FHE list (0-indexed)
  • byte 30: type of the ciphertext
  • byte 31: version

Non-input handles have the following format:

  • byte 0 to 29: first 30 bytes of keccak256(serialized compact FHE list)
  • byte 30: type of the ciphertext
  • byte 31: version

Above allows us to pack multiple inputs in one or more CompactFheUint160Lists.

Add support for equality and non-equality of FheUint2048 values.

Cleanup should be done in a future commit in order to remove unused code, duplication and to simplify the implementation and the tests, especially around tfhe-rs handling.

@dartdart26 dartdart26 self-assigned this Jun 17, 2024
@dartdart26 dartdart26 marked this pull request as draft June 17, 2024 09:52
@jatZama
Copy link
Member

jatZama commented Jun 17, 2024

Does this support equality of encrypted 2048 bits with cleartext bytes array of length 2048?

@jatZama
Copy link
Member

jatZama commented Jun 17, 2024

Also note that the trivialEncrypt signature would need to change just for the 2048 bits, because it cannot fir in a uint256...

@dartdart26 dartdart26 force-pushed the petar/list-based-inputs branch 2 times, most recently from 689a807 to b534785 Compare June 17, 2024 13:40
@dartdart26
Copy link
Collaborator Author

Does this support equality of encrypted 2048 bits with cleartext bytes array of length 2048?

I added it.

@dartdart26
Copy link
Collaborator Author

Also note that the trivialEncrypt signature would need to change just for the 2048 bits, because it cannot fir in a uint256...

Good point, let's leave it for the future, the PR is huge as it is.

@dartdart26 dartdart26 marked this pull request as ready for review June 17, 2024 13:54
Copy link
Contributor

@immortal-tofu immortal-tofu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very heavy PR, but I didn't see any issue. It looks good to me.

@dartdart26 dartdart26 force-pushed the petar/list-based-inputs branch 2 times, most recently from cfe51dc to cda5c9f Compare June 17, 2024 16:19
Add support for list-based ciphertext inputs. Two types are supported:
 * CompactFheUint160List
 * CompactFheUint2048List

No other input types are supported. Instead, the `fhevmjs` library
encodes any type other than the FheUint2048 type as FheUint160. In
fhevm-go during ciphertext verification, we cast it homomorphically to
the requested data type. FheUint2048 values are expanded as is, without
any casts.

The API of the verifyCiphertext precompile changes such that now it
accepts two inputs (through TFHE.asEuintXX() library function in
fhevm):
 * bytes32 Handle
 * serialized compact FHE list

Handle format changes and is no longer the hash of the expanded
ciphertext. Instead, input handles have the following format:
 * byte 0 to 28: first 29 bytes of
   keccak256(keccak256(serialized compact FHE list) || index)
 * byte 29: index in the serialized compact FHE list (0-indexed)
 * byte 30: type of the ciphertext
 * byte 31: version

Non-input handles have the following format:
* byte 0 to 29: first 30 bytes of keccak256(serialized compact FHE list)
 * byte 30: type of the ciphertext
 * byte 31: version

Above allows us to pack multiple inputs in one or more
CompactFheUint160Lists.

Add support for equality and non-equality of FheUint2048 values.

Cleanup should be done in a future commit in order to remove unused
code, duplication and to simplify the implementation and the tests,
especially around tfhe-rs handling.
dartdart26 added a commit to zama-ai/fhevm that referenced this pull request Jun 18, 2024
More info: zama-ai/fhevm-go#120

API changes will be described in the documentation.

More tests and examples are to be done in a future commit.
@dartdart26 dartdart26 merged commit d22f070 into main Jun 18, 2024
2 checks passed
@dartdart26 dartdart26 deleted the petar/list-based-inputs branch June 18, 2024 09:15
dartdart26 added a commit to zama-ai/fhevm that referenced this pull request Jun 18, 2024
More info: zama-ai/fhevm-go#120

API changes will be described in the documentation.

More tests and examples are to be done in a future commit.
dartdart26 added a commit to zama-ai/fhevm that referenced this pull request Jun 18, 2024
More info: zama-ai/fhevm-go#120

API changes will be described in the documentation.

More tests and examples are to be done in a future commit.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants