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

Serialization inconsistency detection #504

Merged
merged 4 commits into from
Nov 18, 2024
Merged

Conversation

lehugueni
Copy link
Contributor

@lehugueni lehugueni commented Oct 15, 2024

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.PublicKey
  • rlwe.SecretKey
  • rlwe.Ciphertext
  • rlwe.GaloisKey
  • rlwe.MemEvaluationKeySet
  • bgv.Parameters
  • ckks.Parameters

It also adds a method rlwe.Encryptor.NewTestEncryptorWithPRNG() that can be used to generate a deterministic encryptor for testing purposes.

@lehugueni lehugueni added the tests Issue or PR related to the tests label Oct 15, 2024
@lehugueni lehugueni self-assigned this Oct 15, 2024
Copy link

@MGeorgie MGeorgie left a comment

Choose a reason for hiding this comment

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

Seems good for me

core/rlwe/encryptor.go Outdated Show resolved Hide resolved
@ChristianMct
Copy link
Collaborator

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.

@lehugueni
Copy link
Contributor Author

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.

@Pro7ech
Copy link
Collaborator

Pro7ech commented Oct 16, 2024

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.

@lehugueni
Copy link
Contributor Author

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.

@lehugueni lehugueni merged commit 3662ccc into main Nov 18, 2024
3 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tests Issue or PR related to the tests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants