I am currently trying to integrate an outside (not in openfhe) lightweight cipher (LWC) with the library in order to be able to perform computation on the LWC ciphertext without decrypting. I was pointed to PRE and agree it seems the best approach; however, I have a few small integration questions:
I have been looking at the pre-buffer.cpp example. The key length from KeyGen() appears to be only 28bits. Is this always the case or is it possible to generate a strong/longer key?
Is there a way to convert a std::vector<int64_t> ciphertext (what I generate from the LWC) into a Ciphertext that the library specifies? The std::vector<int64_t> is a little flexible in what I can assign it to; however, it will be some cpp native type like char, char , unint8_t, etc.
I have looked at the serial examples in palisade-serial-examples, specifically the AES PRE example, but it’s unclear how it actually converts everything. Any guidance/advice would be greatly appreciated.
For the first question, the ciphertext modulus size in FHE/lattice cryptography does not directly map to the work factor (bits of security). The work factor is estimated using the tables for the Learning With Errors (LWE) problem. See table 1 at http://homomorphicencryption.org/wp-content/uploads/2018/11/HomomorphicEncryptionStandardv1.1.pdf for the tables adopted by the FHE community (the default option corresponds to (-1,-1) secret key distribution). The default security level corresponds to at least 128 bits of secure for classic computer attacks.
For the second question, you can decompose any number into smaller digits (by default, the plaintext modulus of 65537 is used) and store in different coefficients if you do not need to support any homomorphic computations, i.e., you just need PRE. For instance, you can decompose a 64-bit number into a vector of 4 16-bit numbers. In other words, your input vector would be 4 times larger.
If you need to support homomorphic computations over 64-bit numbers, then it gets a little bit trickier. Currently, the maximum plaintext modulus is 32 bits (we will expand it to 64 bits by the time the stable version is released). Chinese Remainder Theorem for the plaintext could be used to support more than 32-bit plaintext moduli at this point (but this gets somewhat more complicated).
What specifically are you trying to do? There may be a more efficient way to do it.
So I am attempting to use HE in conjunction with an LWC as a Cross Domain Solution. The steps I am sort of attempting to take are:
Encrypt pt using the LWC (for example, one of the finalists from the NIST Lightweight Cryptography Competition) to get ct
Take the ct produce and convert it into an HE ciphertext, call it hct, in this case through PRE
Perform computations on the hct in order to compare with certain attributes to determine if it should be passed through the router
If yes, then pt would be sent
Overall, the HE portion of this is just to be able to perform computations to check certain message details, as to whether a router/gateway has the correct clearance/permissions without exposing the data. I hope this clarifies what I am hoping to accomplish. The main issue I have been running into through my development is mostly type conversions to properly be able to integrate into the OpenFHE library
Converting an existing ciphertext encrypted using a non-HE scheme to an HE-capable ciphertext requires transciphering, and cannot be done using PRE. The high-level idea of tranciphering is to evaluate the decryption circuit for the LWC (in this case) using an FHE scheme. The first work that demonstrated this was Homomorphic Evaluation of the AES Circuit (AES was the input cipher, but the complexity of evaluating the AES circuit using FHE is quite high). There are more recent works that use a more FHE-friendly decryption circuit, for example, PASTA (Pasta: A Case for Hybrid Homomorphic Encryption).
The purpose of PRE in OpenFHE is to switch an existing FHE ciphertext (encrypted using BGV, BFV, or CKKS) from one secret key to another without having access to either of the secret keys (or the original secret key). This re-encryption is done using a special (public) re-encryption key.
Okay, thank you for clarifying and the advice. I guess I receive initially inaccurate PRE information. Thanks for the recommendations, I shall check those out and see if they can help solve my issue.
Hi @ypolyakov I am a complete newby when it comes to encryption. I was after the same solution @cdailey seems to be presenting i.e. using non HE encryption schemes found on most languages together with FHE on the Proxy. If I get it right that is not possible. So, are you aware of any practical scheme which will allow me to deploy PRE on multiple platforms without the need to create bindings of OpenFHE on each one e.g.use another FHE implementation on the client e.g, MSFT Seal, etc. together with OpenFHE on the Proxy? Thanks a lot in advance
Thank you for your question. First, I would like to add a clarification. MSFT SEAL implements the same FHE schemes as OpenFHE, i.e, BGV, BFV, and CKKS (OpenFHE also implements some additional schemes + threshold FHE + PRE). So I do not really see any benefit in using both SEAL and OpenFHE if both FHE and PRE are needed (OpenFHE can handle both).
The main problem is in converting a non-FHE scheme to an FHE one. In addition to the prior paper on PASTA, I suggest looking at Section VIII of Survey on Fully Homomorphic Encryption, Theory and Applications and a later paper on FASTA (FASTA - a stream cipher for fast FHE evaluation). One can theoretically implement AES to FHE conversion in OpenFHE using the FHEW/TFHE schemes (see around 30:00 in the webinar on Boolean applications: Homomorphic Encryption for OpenFHE Users – OpenFHE.org), but this would be very slow for use in practice at this time. In summary, efficient conversion from a non-FHE scheme to an FHE one is currently an active topic of research.
@ypolyakov thanks for the prompt reply and the extra materials.
The idea to combine SEAL and OpenFHE was so that I can use already implemented bindings for other languages than C++, which AFAIK are not available from OpenFHE. For example SEAL offers Python, Typescript and JavaScript bindings so that would enable me to use SEAL on the front end for example while using OpenFHE on the backend performing PRE.
Not sure what level of support you need, but there is the open source JS bindings Palisade-WASM. Unfortunately, we haven’t had time to move the code over to OpenFHE yet, but I wanted to make you aware of its existence
Brilliant, thanks a lot! I need to start a prototype implementation now, so could you confirm that I should be able to encrypt with MSFT SEAL and re-encrypt with OpenFHE when using the same FHE scheme on both libs? BTW if this prototype works it would result in an OpenFHE binding for Erlang
The serialization formats for SEAL and OpenFHE are significantly different. So it will not work. Serialization interoperability between libraries is something we discussed at one of the earlier standards meetings, but this topic appeared premature at the time.
If you only need JavaScript and TypeScript bindings, then you could use PALISADE for now. The migration from PALISADE to OpenFHE (once JS and TS bindings are added to OpenFHE) should be relatively straightforward. There is also a light Python wrapper for PALISADE: PALISADE / PALISADE Python 3 Demos · GitLab . Hopefully this is helpful.
