Closed carlee0 closed 3 years ago
Wow, thanks for your work. I was thinking do it by myself not long ago. My main idea is not to change any code in the seal. I'm happy to see it.
The c++ source code of SEAL is left intact. Much of the work has been done in your earlier release and lab41. I merely added a deserialisation that supports the additional argument of SealContext. Glad it is of any help. :)
I noticed that loading is still not working properly with the objects requiring context. They remain none objects after loading. Reopening the issue and I will see if I can find a fix.
I find it unfeasible using pickle for the objects needing SealContext. A slight different approach of saving to and loading from printable strings are now added in #22. Corresponding tests for saves()
and loads()
of Plaintext
and Ciphertext
have also been added in the tests.
It looks like you found out about it. The problem is you cannot pass two more parms into one pickle.
Yeah. I realised that after many failed attempts. :) Even tried to combing the But it's still nice with the ability of saving to strings. The communication is a lot leaner.
Too bad, it is still not platform agnostic without pickling.
Would it be possible to piece together the bytes of a context and a seal object, and pass it to the loads
?
That would be a solution, but you also need pass the other parms in it.
For exmaple, add the needed parms in the class like Ciphertext
, then we can pickle them together.
But I don't wish this, it need to change the SEAL's code, not as good as you did.
Hi, it is quite inconvenient to always have to save and load from a binary file when working with the library. Another issue is the binary file compatibility (rather lack of) across different operating systems.
So I went ahead and added support for pickling (inspired by your earlier release and lab41's repo). It is quite useful to be able to
pickle.dumps()
the python object to a printable string to pass to a different process. I can open a PR if the feature is desired. Cheers!