Our team has been working on making FHE practical. Performance has come a long way in the past few years so FHE can indeed be "practical" for certain applications.
If you'd like to check it out yourself, feel free to take a look at our team's FHE compiler and playground [0].
I don't think it was just a press release, the linked PDF had a nice overview of how we got here and some advances in the last decade. Decent little review type article with some hyperbole!
I think the title maybe a little too optimistic / vague by saying it's "near" without indicating what else is needed to get there / when it might happen ;).
The byline is "Mache Creeger, Cornami Inc.". Cornami is a company that sells FHE accelerator chips. Many of the talking points seem to be very similar to the Cornami website, such as the over-emphasis on post quantum crypto despite being very irrelavent in context.
Doesn’t fully homomorphic encryption have the Tux Image problem cited in block cypher discussions?
With a symmetric cipher, I could figure out the blood type of every employee pretty easily. With an asymmetric cipher, I could figure out everyone who has my blood type, and the blood types of anyone who reveals that information.
If the point is to filter data when you aren’t allowed to know what the data is, then the act of being in the filter or not reveals some of that information. It’s just a game of twenty questions.
I think you are mixing it up with order-preserving encryption and other stuff related to encrypted databases.
In the FHE model, the assumption usually is - you have some data, someone else does some encrypted calculations, you get the encrypted answer back, you decrypt the answer and read it. The adversary cannot play 20 questions because they only calculate the encrypted answers, they are not allowed to see what the answers are.
I think you are thinking of how ECB ends up with the identical blocks having identical encrypted form due to key and IV reuse. I don't think this is a requirement for all forms of FHE.
In particular, most FHE schemes inherently add randomness to encryptions as an artifact of using Ring Learning with Errors (RLWE) for hardness. This means that Enc(pk, m) != Enc(pk, m) if you run the algorithm twice; each key and message pair can produce many different ciphertexts.
It's always nice to see when some new field has managed not to experience every single classic blunder firsthand to learn not to do that. So there is something akin to a salt in the data that keeps identical records from being searchable, that's good to know.
Do you by chance have a simple way to explain how the search works then? Because superficially it seems like you might assume that you're looking for Enc(pk, m') == Enc(pk, m) and apparently that does not work.
By search, I assume you mean how would you do a database search with FHE referred to in the article. A simple example of private information retrieval is as follows:
Suppose Bob has an array of data he arranges into an mxn matrix, A. This data is not encrypted, but is encoded appropriately. Note that many FHE schemes allow you to compute ciphertext-plaintext operations.
Alice can send him 2 vectors x and y encrypted under her key, where x and y are all zero except for single 1. Bob homomorphically computes Ax = b. Since x is all zeros except for element i, the operation Ax effectively selects the ith column of A. Bob then computes dot(b, y). Since y is all zeros except for a 1 at element j, the dot product effectively selects the jth row of y. Bob sends the dot product back to Alice, which due to FHE is still encrypted under her key.
Alice decrypts the result and has looked up the j,ith element in A without Bob learning Alice's query or which data was involved in processing her search.
The default program on the Sunscreen[1] compiler playground shows this exact algorithm.
Would practical FHE be interesting? Sure. Is it happening? Doesn't seem like it is any time soon.