awslabs/homomorphic-implementors-toolkit

Improve ciphertext serialization

Closed this issue · 1 comments

We should be able to serialize ciphertexts in two ways.

  1. As a standalone ciphertext. This means the ciphertext should include its HE parameters. The use case for this serialization method is sending a single ciphertext over the wire.
  2. As a raw ciphertext, without HE parameters. This gives an efficient serialization method for settings where we need to serialize many ciphertexts, all of which have the same parameters. For example, in the linear algebra API, we need to serialize a matrix which has a two dimensional array of ciphertexts. It's a waste to have them all store metadata, so the matrix itself should store HE parameters, along with a list of raw ciphertexts.
  3. This also means we need a standalone Proto object for HE parameters.

Thus the Proto structure is:

  • HE parameters (we have this)
  • Raw ciphertext (SEAL ciphertext + level, scale, and plaintext)
  • "Normal" ciphertext (HE parameters + raw ciphertext)

After more thought, it's not clear how this would work in practice. The problem is that we have to use the parameters to create a CKKSInstance, and then use the instance to parse the encrypted objects. If this were packaged as a single object the process would look something like:

  1. Read the binary blob as a proto object
  2. Using just the "parameters" part of the proto object, create a CKKSInstance
  3. Using the CKKSInstance and the rest of the proto object, parse the encrypted object.

This involves a choice for what type of instance to create, as well as which object to deserialize, resulting in a cross-product of deserialization functions.

Another reason this is hard is because of Galois and relinearization keys. Due to their size, we can't use protocol buffers for them, they must be serialized directly with SEAL into their own binary blobs and transmitted separately. They must be used in step (2) above to create the instance, so we're already dealing with multiple files that must be tracked.

Although this is a nice idea in concept, it doesn't seem to work well in practice. Tabling until we have a clearer path.