tuneinsight
Serialization inconsistency detection
Add tests that detect if the serialization or the generation of critical objects changes.
Context: Changing serialization might lead to problems such as an incompatibility between parties running different versions of lattigo, or the impossibility to load objects serialized with lattigo vX in lattigo vX+1. These tests allow for early detection of such issues.
The serialization/generation of the following objects are tested:
rlwe.PublicKeyrlwe.SecretKeyrlwe.Ciphertextrlwe.GaloisKeyrlwe.MemEvaluationKeySetbgv.Parametersckks.Parameters
It also adds a method rlwe.Encryptor.NewTestEncryptorWithPRNG() that can be used to generate a deterministic encryptor for testing purposes.
I'd leave the change to the Encryptor type for another PR.
In the current state it seems we're missing important functionality:
- instantiating an Encryptor with seeded uniform PRNG -> can reduce the size of sk-encrypted CT by half.
- instantiating an Encryptor with seed secrets' distribution -> local ciphertext re-randomization from the public-key
- Both of the above -> for tests, as observed.
In the current state it seems we're missing important functionality:
* instantiating an Encryptor with seeded uniform PRNG -> can reduce the size of sk-encrypted CT by half.
There is a way to instantiate the uniform sampler of the encryptor with a given PRNG since lattigo v6.1.0 (Encryptor.WithPRNG) :)
In the end we need a way to generate deterministic objects for this PR specifically.
So maybe I can make it clear in the PR title/description that we add such a function, and then we can create another issue/PR detailing other use cases and how to unify these functions.
In the current state it seems we're missing important functionality:
* instantiating an Encryptor with seeded uniform PRNG -> can reduce the size of sk-encrypted CT by half.There is a way to instantiate the uniform sampler of the encryptor with a given PRNG since lattigo v6.1.0 (
Encryptor.WithPRNG) :)In the end we need a way to generate deterministic objects for this PR specifically.
So maybe I can make it clear in the PR title/description that we add such a function, and then we can create another issue/PR detailing other use cases and how to unify these functions.
These tests will also break if there is a change in any of the sub-routine used to generate the objects. I don't know if that's the goal, since it's explicitly stated that this is to check that the serialization is stable. The only way to prevent this is to have the keys, ciphertexts and plaintexts serialized in files and check it deserializes and decrypts correctly.
These tests will also break if there is a change in any of the sub-routine used to generate the objects. I don't know if that's the goal, since it's explicitly stated that this is to check that the serialization is stable. The only way to prevent this is to have the keys, ciphertexts and plaintexts serialized in files and check it deserializes and decrypts correctly.
Yes, I think the long-term goal would be that the generation of these basic objects stays stable as well, like with any standardised algorithm. So it's probably a positive "side-effect" of these tests and we avoid storing test objects. I've edited the description to make it clearer.