My Journey into Homomorphic Encryption Libraries
A bit about myself: my background was originally in machine learning (ML), and one of my particular interests was privacy-preserving machine learning (PPML). The idea of unlocking insights while keeping the underlying data private was something I’ve always found fascinating. This interest in PPML led me to OpenMined.org, an open-source organization working on PPML. While at OpenMined, I gained some exposure to Fully Homomorphic Encryption (FHE) through TenSEAL, OpenMined’s native wrapper around Microsoft’s SEAL library. However, because I lacked a background in cryptography, I found it challenging to understand and contribute to TenSEAL.
Thus, I began my search for a library that was accessible (coming from ML, my primary programming language was Python), easy to use, and expository in nature; all necessary qualities for someone new to the area and looking to get caught up. While shopping around, I stumbled upon OpenFHE (formerly PALISADE), which ticked all of my boxes.
Based on my experience, I’d say that choosing a Homomorphic Encryption library is much like choosing any other library. The main difference is that the HE community tends to be smaller, and the level of knowledge required to get up to speed is slightly higher.
Here are the criteria I considered while choosing a Homomorphic Encryption library:
As an end-user, I’ve found that how a library lays out information is very important. Too much information leaves the user overwhelmed, and they end up skipping over important text, but presenting too little information leaves the user confused and unable to use the library properly.
As a newbie (and even now that I’ve got my wings), I think that OpenFHE (openfhe.org) is one of my favorite libraries in how it lays out its information as, for the most part, OpenFHE balances the line very well. I felt that the expository-esque nature lent itself quite well to my style of learning and that it felt almost academic in nature (no surprise given the authors’ backgrounds).
That’s not to say there weren’t any hiccups: there were duplicate pages in the documentation, some URLs pointed to dead links, and some sections referenced old code. Thankfully, these issues weren’t blockers and did not prevent me from learning. Nevertheless, the team has been hard at work fixing these issues and I’m happy to say that the library is more accessible than ever.
The second factor was the size of the community. A larger community of library users would mean there are more people who could help me with my bugs and clarify my misunderstandings. Furthermore, a larger community would mean more innovation from users. For example, there is a port of OpenFHE to WebAssembly, which some community members created. Contributions like these are less likely to happen if there isn’t a sizable community around the homomorphic encryption library.
Although a library like SEAL has android support, it is driven largely by an internal team, which means that unless it’s 1) part of a product or 2) a user has reported a bug, it’s unlikely to get updates. As of this time, the Android port was last updated over a year ago.
The third factor was the amount of community engagement. Do the developers hold office hours? Are they hosting webinars or events about their library? Are they sharing up-and-coming features?
As a developer, I’ve seen my fair share of libraries gradually deprecate or fall out of date. It’s understandable that this happens – hosting a successful open-source project is difficult and time-consuming. However, as a user, you also want to feel confident that the critical tool to your project or product will still be around in a few months or years.
In that sense, I felt comfortable turning to OpenFHE because I knew that Duality Technologies (dualitytech.com) heavily utilized the library internally.
Unfortunately, this is the most nebulous criteria of all. Sometimes the library design clicks, and you understand why the authors wrote it the way they did, but sometimes you’re left scratching your head. Other times, it could just be that there’s too much friction in terms of the programming language, which is what happened in my case.
Before I settled on OpenFHE, I checked out various other HE libraries such as Concrete (Rust), Lattigo (Go), and SEAL (C++). At the time, of those languages, I was most proficient in C++, which meant that if I wanted to focus on learning HE (as opposed to a new language), I would have to use OpenFHE or SEAL.
A criterion that I considered non-negotiable was that the library should be open-source. As an open-source software advocate, I firmly believe that if a cryptography library is not being transparent with its code, it is a red flag. There are arguments that open-sourced libraries are no more secure than closed ones, but I’d argue that those result from human error rather than the principles themselves.
Furthermore, I believe that a homomorphic encryption library that does not open-source code is not interested in helping the community. There is the adage of “Don’t roll your own crypto,” because you are likely to introduce bugs or not consider edge cases. If that is the case, I believe more eyes on the code would result in safer code as you are more likely to catch those errors.
The final criterion was to find a library that was standards compliant. While learning more about homomorphic encryption, I unsurprisingly stumbled onto the Homomorphic Encryption Standardization organization. In their paper, they established scheme descriptions, detailed descriptions of their security properties, and tables for secure parameters.
Given cryptographers are concerned with worst-case scenarios, it is unsurprising that establishing security standards is essential. After all, if your cryptography algorithms are not secure, then the programs you build off of those libraries are not secure. And so, in my search I highly prioritized a library that was standards compliant.
I’ll start with how my search ended. My favorite library ended up being OpenFHE (formerly PALISADE) out of all the libraries I had evaluated. Although it had flaws, I felt that OpenFHE was the best library for me at the time. It certainly helped that the developer team was active in community engagement by hosting webinars and information sessions. I worked with OpenFHE for a bit before meeting the team members at Duality, who were friendly and helped me with various questions. After some time, I was invited to join the team and push FHE forward; the rest is history!
When I officially joined the Duality team as a Software Engineer, I got to work alongside other talented people on the next generation of PALISADE: OpenFHE (openfhe.org). My background (or lack of) in Homomorphic Encryption meant that I had insight into the problems new users would face while learning the library. Using the insights I had gained, I worked on rehauling the documentation to increase its usability, while maintaining the original functionality. Additionally, the team restructured the library structure to aid new users in terms of understanding how the code is laid out, and to assist new users in the learning process.
In this section, we cover a few of the other FHE libraries (in no particular order):
As mentioned above, Concrete was written in Rust, a language consistently receiving rave reviews among developers. Zama, the team behind Concrete, also released two separate libraries: Concrete-numpy and Concrete-ML, which facilitate encrypted numerical computation.
Concrete-Numpy is the base on which you can build encrypted numerical operations. Concrete-Numpy provides capabilities such as vector and matrix operations in a format familiar to data scientists. On the other hand, Concrete-ML expands on Concrete-Numpy by composing the API to enable machine learning on encrypted data like the famous ML library, Scikit Learn.
One thing to note, however, is that Concrete only supports the Fully Homomorphic Encryption over the Torus (TFHE) scheme, which is limited to boolean and integer values. Furthermore, their LICENSE, specifically the patent requirements could be interpreted as being invasive. In addition, potential contributors must sign a Contributor License Agreement before being allowed to open pull requests. Contributor License Agreements have long been a controversial topic in open source. To learn more about this nuanced topic, read opensource.com: Why CLAs aren’t good for open source.
As mentioned above, SEAL is another FHE library maintained by Microsoft and written in C++. In terms of popularity, SEAL is by far the most popular library, with 2,600 stars on their Github. However, despite its substantial reach, I felt like it lacked a sense of community. Nowhere on the Github page did I find resources to connect with other individuals using SEAL. As mentioned above, this lack of community and engagement from the devs made the library less appealing.
Furthermore, when I was evaluating SEAL, I found that their documentation was incredibly intimidating. On the one hand, the SEAL developers thoroughly described what was happening in the code. On the other hand, seeing so many lines of code representing a program subsection left me feeling intimidated and discouraged as a potential end-user and novice. Additionally, as with Concrete, to contribute to this library one has to sign a Contributor License Agreement.
Last but not least is Lattigo, which is written in Go. As in the case of SEAL, Lattigo has a substantial number of stars on Github (our proxy for popularity and community size), making it a great candidate for me. Also, from what I have heard, Go is a valuable language to learn and is not too difficult to get up to speed with, reducing friction. Unfortunately, I had no way of connecting with the community of users, and there did not seem to be community engagement from the developers.
Hopefully, this article has provided helpful information for you to decide what library to adopt for your application. If you’d like to learn more about OpenFHE please check out our GitHub (https://github.com/openfheorg/openfhe-development) and Discourse group (https://openfhe.discourse.group/) – we’d love to have you be part of our community!
P.s I highly recommend looking through the security standards paper I mentioned above. I found the paper particularly useful from two fronts:
