feat(tfhe): add zk-pok code base #1050

IceTDrinker · 2024-04-04T11:47:15Z

integration of work done by Sarah in the repo

IceTDrinker · 2024-04-08T07:24:30Z

cuda C API tests likely need the ZK pok feature @tmontaigu

IceTDrinker

Some comments that were waiting apparently, will continue this afternoon

Makefile

IceTDrinker · 2024-04-05T15:37:21Z

tfhe/Cargo.toml

@@ -69,6 +69,8 @@ paste = "1.0.7"
 fs2 = { version = "0.4.3", optional = true }
 # While we wait for repeat_n in rust standard library
 itertools = "0.11.0"
+rand_core = { version = "0.6.4", features = ["std"] }
+tfhe-zk-pok = { version = "0.1.0", path = "../tfhe-zk-pok", optional = true}


formatting, missing space before } , we'll add toml formatter at some point I guess but I don't think I found one that's easy to setup with e.g. rust

IceTDrinker · 2024-04-05T15:37:41Z

tfhe/Cargo.toml

@@ -270,6 +273,10 @@ required-features = ["boolean", "shortint", "internal-keycache"]

 # Real use-case examples

+[[example]]
+name = "demo"


zk-pok-demo maybe ?

IceTDrinker · 2024-04-05T16:12:55Z

tfhe/src/integer/server_key/radix_parallel/ilog2.rs

@@ -241,6 +241,7 @@ impl ServerKey {
        let counter_num_blocks = ((num_bits_in_ciphertext - 1).ilog2() + 1 + 1)
            .div_ceil(self.message_modulus().0.ilog2()) as usize;

+        // 11111000


what's that ?

I was explaining something via zoom and used that file as a whiteboard

IceTDrinker

in the core part there are some confusions between parallel and non parallel variants it seems, and some debug code is still there, I marked the biggest ones.

Also the private param of the CRS should not be available in the CRS structure otherwise I believe the security of the ZK falls, ping me if you need help

IceTDrinker · 2024-04-08T11:36:25Z

tfhe/src/core_crypto/commons/math/random/generator.rs

+    fn next_u32(&mut self) -> u32 {
+        let mut bytes = [0u8; std::mem::size_of::<u32>()];
+        bytes.iter_mut().for_each(|b| *b = self.generate_next());
+        u32::from_ne_bytes(bytes)


use the uniform generation from the already implemented Uniform distribution if needed or use from_le_bytes, I believe from_le_bytes was preferred to avoid endianness issues cross platform

tfhe/src/core_crypto/commons/math/random/uniform.rs

IceTDrinker · 2024-04-08T11:36:32Z

tfhe/src/core_crypto/commons/math/random/generator.rs

+    fn next_u64(&mut self) -> u64 {
+        let mut bytes = [0u8; std::mem::size_of::<u64>()];
+        bytes.iter_mut().for_each(|b| *b = self.generate_next());
+        u64::from_ne_bytes(bytes)
+    }


same thing as above

IceTDrinker · 2024-04-08T11:39:09Z

tfhe/src/core_crypto/commons/math/random/mod.rs

+    }
+}
+
+impl<T> BoundedDistribution<T, T::Signed> for TUniform<T>


isn't low supposed to be equal to high given the trait definition above ?

No, Low = High in the trait definition is just to set Low as by default being the same type as High, we it can be anything else

ok got it, we may want to be consistent here and have everything with a single type wdyt ?

IceTDrinker · 2024-04-08T11:39:29Z

tfhe/src/core_crypto/commons/math/random/mod.rs

+    fn low_bound(&self) -> Bound<T::Signed> {
+        Bound::Included(self.min_value_inclusive())
+    }
+
+    fn high_bound(&self) -> Bound<T> {
+        Bound::Included(self.max_value_inclusive().into_unsigned())
+    }


any reason here to have different signedness for both bounds ?

for flexibility

IceTDrinker · 2024-04-08T11:43:08Z

tfhe/web_wasm_parallel_tests/index.html

+    <input
+      type="button"
+      id="compactPublicKeyZeroKnowledgeBench"
+      value="Compact zk bench"


I think nit needs bench with a capital B to be picked up by our filter and I had issues with that last week

you adjusted time outs right ?

IceTDrinker · 2024-04-08T12:06:00Z