zama-ai / tfhe-rs

TFHE-rs: A Pure Rust implementation of the TFHE Scheme for Boolean and Integer Arithmetics Over Encrypted Data.
Other
907 stars 143 forks source link

Am/feat/raw parts for ksk #1411

Closed IceTDrinker closed 2 months ago

titouantanguy commented 2 months ago

FYI, managed to fit my distributed generated keys into tfhe-rs types and run the following test when using Small destination_key and Big encryption_key_choice (i.e. when the PBS cleans up the noise during expand).

fn try_tfhe_pk_compactlist_computation(
        client_key: &tfhe::ClientKey,
        server_keys: &tfhe::ServerKey,
        pk: &tfhe::CompactPublicKey,
    ) {
        let clear_a = 3u64;
        let clear_b = 5u64;

        let compact_ctxt_list = tfhe::CompactCiphertextList::builder(pk)
            .push(clear_a)
            .push(clear_b)
            .build_packed();

        let result = {
            set_server_key(server_keys.clone());
            let all_keys = server_keys.clone().into_raw_parts();
            let cpk_ksk = all_keys.2;
            assert!(cpk_ksk.is_some());
            // Verify the ciphertexts
            let expander = compact_ctxt_list.expand().unwrap();
            let a: tfhe::FheUint64 = expander.get(0).unwrap().unwrap();
            let b: tfhe::FheUint64 = expander.get(1).unwrap().unwrap();

            a + b
        };

        let a_plus_b: u64 = result.decrypt(client_key);
        assert_eq!(a_plus_b, clear_a.wrapping_add(clear_b));
    }

Still not 100% clear to me what are the trade-offs of the different combinations of Small/Big for destination_key/encryption_key_choice, and I am not sure what the NIST doc (which is the reference doc. for us) says about it (I am guessing this choice has implication wrt which parameters to use)

IceTDrinker commented 2 months ago

I think the doc does small -> small and big -> big

but if we keyswitch to the small key then we have a smaller keyswitching key to generate, though you will need to bootstrap in the case where the encryption key is the big one