tfhe-rs
sdk
tfhe-rs | sdk | |
---|---|---|
4 | 4 | |
778 | 324 | |
6.7% | 0.6% | |
9.9 | 3.4 | |
3 days ago | about 2 months ago | |
Rust | Rust | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
tfhe-rs
-
Homomorphic Encryption: Universality at a Cost
Yes, there are working FHE systems: e.g., TFHE-rs by Zama. Unfortunately, it requires a pretty low-level representation of the computation of interest (as a Boolean circuit), and the resulting performance overhead is a bit too high (e.g., comparing two 32-bit integers takes around 9 seconds on a single core), but IMO it's already in the state where a few select applications are becoming possible via FHE.
-
Encrypted Image Filtering Using Homomorphic Encryption (a demo + a tutorial)
Hello all, As some of you know (or not), we're working on Fully Homomorphic Encryption at Zama (We created TFHE-rs, a rust implementation of the TFHE scheme. We're working hard to make FHE practical and not just a cryptographer's dream anymore :')
- TFHE-rs: The fastest open source Homomorphic Encryption library
-
The fastest open source Homomorphic Encryption library
You can try it here (it's fully open-source): https://github.com/zama-ai/tfhe-rs
sdk
-
Launch HN: Blyss (YC W23) – Homomorphic encryption as a service
Hi everyone! I’m Samir, and my co-founder Neil and I are building Blyss (https://blyss.dev). Blyss is an open source homomorphic encryption SDK, available as a fully managed service.
Fully homomorphic encryption (FHE) enables computation on encrypted data. This is essentially the ultimate privacy guarantee - a server that does work for its users (like fetching emails, tweets, or search results), without ever knowing what its users are doing - who they talk to, who they follow, or even what they search for. Servers using FHE give you cryptographic proof that they aren’t spying on you.
Unfortunately, performing general computation using FHE is notoriously slow. We have focused on solving a simple, specific problem: retrieve an item from a key-value store, without revealing to the server which item was retrieved.
By focusing on retrievals, we achieve huge speedups that make Blyss practical for real-world applications: a password scanner like “Have I Been Pwned?” that checks your credentials against breaches, but never learns anything about your password (https://playground.blyss.dev/passwords), domain name servers that don’t get to see what domains you’re fetching (https://sprl.it/), and social apps that let you find out which of your contacts are already on the platform, without letting the service see your contacts (https://stackblitz.com/edit/blyss-private-contact-intersecti...).
Big companies (Apple, Google, Microsoft) are already using private retrieval: Chrome and Edge use this technology today to check URLs against blocklists of known phishing sites, and check user passwords against hacked credential dumps, without seeing any of the underlying URLs or passwords.
Blyss makes it easy for developers to use homomorphic encryption from a familiar, Firebase-like interface. You can create key-value data buckets, fill them with data, and then make cryptographically private retrievals. No entity, not even the Blyss service itself, can learn which items are retrieved from a Blyss bucket. We handle all the server infrastructure, and maintain robust open source JS clients, with the cryptography written in Rust and compiled to WebAssembly. We also have an open source server you can host yourself.
(Side note: a lot of what drew us to this problem is just how paradoxical the private retrieval guarantee sounds—it seems intuitively like it should be impossible to get data from a server without it learning what you retrieve! The basic idea of how this is actually possible is: the client encrypts a one-hot vector (all 0’s except a single 1) using homomorphic encryption, and the server is able to ‘multiply’ these by the database without learning anything about the underlying encrypted values. The dot product of the encrypted query and the database yields an encrypted result. The client decrypts this, and gets the database item it wanted. To the server, all the inputs and outputs stay completely opaque. We have a blog post explaining more, with pictures, that was on HN previously: https://news.ycombinator.com/item?id=32987155)
Neil and I met eight years ago on the first day of freshman year of college; we’ve been best friends (and roommates!) since. We are privacy nerds—before Blyss, I worked at Yubico, and Neil worked at Apple. I’ve had an academic interest in homomorphic encryption for years, but it became a practical interest when a private Wikipedia demo I posted on HN (https://news.ycombinator.com/item?id=31668814) became popular, and people started asking for a simple way to build products using this technology.
Our client and server are MIT open source, and we plan to make money as a hosted server. Since the server is tricky to operate at scale, and is not part of the trust model, we think this makes sense for both us and our customers. People have used Blyss to build block explorers, DNS resolvers, and malware scanners; you can see some highlights in our playground: https://playground.blyss.dev.
We have a generous free tier, and you get an API key as soon as you log in. For production use, our pricing is usage-based: $1 gets you 10k private reads on a 1 GB database (larger databases scale costs linearly). You can also run the server yourself.
Private retrieval is a totally new building block for privacy - we can’t wait to see what you’ll build with it! Let us know what you think, or if you have any questions about Blyss or homomorphic encryption in general.
-
Show HN: Send private valentines, using homomorphic encryption
Hi HN! I'm a cofounder of Blyss.dev, a YC W23 company building an SDK for homomorphic encryption.
In recent HN discussions of homomorphic encryption, there seems to be a common opinion that it is "too slow to use". I thought it'd be fun to put together a quick, seasonal demo challenging that assumption - here's a realtime database that supports private reads via FHE, used as the backend for an otherwise simple CRUD app. Please do kick the tires!
if my 3am engineering does fall over, and the demo breaks, you can still check out our github repo [0] for more detail on what we think you can practically do with FHE today.
[0] https://github.com/blyssprivacy/sdk
-
Private Block Explorer: check your balance and transactions, without revealing your BTC address
Thanks for checking it out. Right, you should not just take our word for it - you can check our source code or read our paper to see how your data is kept private.
-
Show HN: Read Wikipedia privately using homomorphic encryption
Hi, creator here.
This is a demo of our recent work presented at Oakland (IEEE S&P): https://eprint.iacr.org/2022/368. The server and client code are written in Rust and available here: https://github.com/menonsamir/spiral-rs. The general aim of our work is to show that homomorphic encryption is practical today for real-world applications. The server we use to serve this costs $35/month!
A quick overview: the client uses homomorphic encryption to encrypt the article number that they would like to retrieve. The server processes the query and produces an encrypted result containing the desired article, and sends this back to the client, who can decrypt and obtain the article. A malicious server is unable to determine which article the client retrieved. All search and autocomplete is down locally. The technical details are in the paper, but the high level summary is that the client creates a large one-hot vector of encrypted bits (0’s except for the index of the desired article, where they place a 1) and then the server computes something like a ‘homomorphic dot product’ between the query and the plaintext articles.
I’d like to caveat that this is an in-browser demo to show it is practical to use homomorphic encryption at this scale. As a real product, you’d probably want to distribute a signed client executable (or Electron app) since otherwise, a malicious server could simply deliver bad client JS on the fly.
Happy to answer any questions!
What are some alternatives?
Sunscreen - A compiler for fully homomorphic encryption and zero knowledge proofs
rustls - A modern TLS library in Rust
libreddit - Private front-end for Reddit
grin - Minimal implementation of the Mimblewimble protocol.
mempool - Explore the full Bitcoin ecosystem with mempool.space, or self-host your own instance with one-click installation on popular Raspberry Pi fullnode distros including Umbrel, Raspiblitz, Start9, and more!
universal-android-debloater - Cross-platform GUI written in Rust using ADB to debloat non-rooted android devices. Improve your privacy, the security and battery life of your device.
freenet-core - Declare your digital independence