"Encrypted queries for an encrypted database" could be as straightforward as encrypting both the keys and values using a known public key and putting the results in MySQL. You have to be careful with the claims made around these kinds of things because they often appear to be more complex than they are.

It's not nearly that simple. If your encryption scheme is deterministic then this leaks a ton of information, because anybody with the public key can just encrypt lots of values to reconstruct a mapping between plaintexts and ciphertexts. On the other hand, if your encryption scheme isn't deterministic, then you can't predict what encrypted value you should query for.

Those kinds of problems have never stopped any company from offering a service with a lot of nice graphics on the home page.

Add random data to it, so that all (equivalent) data is the same length. For example, if you have a four byte field that represents some monetary value, add four more bytes of random data and encrypt it.

How would you run queries over that?

Huh? How would you search on any encrypted fields?

No subfield matches, no comparisons other than == and != on the whole field, and only works with deterministic encryption... so leaks like a sieve under many threat models.

lol no it's not.

Up can't do a range on encrypted data. If you encrypt 5 and encrypt 10, how do you expect to compare the encrypted results to see which is greater?

If all you do is key value lookup then sure. But SQL is much richer than that.

Even lookup is not easy to be done securely. You don't want that a malicious server/database knows that you are accessing always that record.

See this discussion about how to achieve that: https://news.ycombinator.com/item?id=31668814

I'm really, really curious to how it actually works under the covers. Needless to say, I'm sceptical, primarily because "near plaintext speed" fundamentally isn't currently possible with true fully homomorphic encryption, at least in my understanding.

For example, they give an example of running queries against data that is never decrypted. I'm very curious as to how they do this. I've used blind indexes [1] to solve the "encrypted data searchability problem" in the past, but with blind indexes you're still left with the fact that you can only do exact matches - you can't sort the data or use less than/greater than queries.

With true FHE you should be able to sort results, but my understanding is that it's several orders of magnitude slower than plaintext searching, so I'm very curious as to what Vaultree is actually doing.

1. https://medium.com/@joshuakelly/blind-indexes-in-3-minutes-m...

> "near plaintext speed" fundamentally isn't currently possible with true fully homomorphic encryption, at least in my understanding.

If you skip the security requirements, applying rot13 twice is a fully homomorphic scheme that achieves plaintext speeds ;)

It's up to them to define "near", but I'd consider https://spiralwiki.com/ (Samir Menon and Prof. David Wu at UT Austin) "nearly" usable compared to regular wikipedia.

From their FAQ and blog posts, I don't believe they apply much FHE. Seems what they do is use work from a different subfield [1], which seems to be able to achieve the required speeds and still be able to work with more complex queries.

Techniques I'm seeing in the Pappas et al. paper mentioned in the history section of [1] to do more complex queries seems pretty cool, and I imagine the performance has been improved a bit in more recent work.

[1] https://en.wikipedia.org/wiki/Searchable_symmetric_encryptio...

Proprietary FHE is like doing card magic on a loaded deck. I'm sure there are technical merits to what they're doing, but because they also refuse to show me how the trick is done, I can similarly assume there are some ugly cut corners inside too.

They figured out that most people just look for buzzwords and are thus easy to separate from their money when it comes to crypto.

Encryption as a service is non-sencical. If the provider has the key, and does the encryption and decryption, then who are you protecting the data from[1]? What magical malicious person are you imagining that would somehow be able to get their hands on the encrypted data without also getting the key?

[1] this is very different from FHE where the provider recieves the data already encrypted, and at no point has access to the decryption key.

Edit: their website claims "Data is never decrypted" but then claims they decrypt it before returning it. So its confusing what they are actually doing - but i am 99% sure they are selling bullshit.

It seems like what they do (maybe?) is encrypt the binary/string data but still let you search or join on it by encrypting queries to the same data? So in other words the operations on the data are not encrypted but the data itself is? This might work for whole words but for partial word matches I think you'd have to do a byte-for-byte character swap which exposes it too much to statistical cryptanalysis? And this still leaves computations on numeric data vulnerable?

What statistics do you have in mind there?

If you're using FHE to encrypt a text search, then you'll generate a match/no-match boolean for each character. The server won't know which is which. Then you'd probably OR large blocks of these together, to give you a match/no-match boolean for each segment of text. Then you return all the booleans to the client, who decrypts them.

> It seems like what they do (maybe?) is encrypt the binary/string data but still let you search or join on it by encrypting queries to the same data? So in other words the operations on the data are not encrypted but the data itself is?

Are you saying something along the lines of - they split the data in to tokens, deterministically (no iv) encrypt each token, and then do equality comparisons on the encrypted tokens?

Maybe, and it would explain why they say you can chose a cipher and then list a bunch of standard symmetric ciphers. However such schemes usually leak too much in practise (even at the granuality of whole words).

More importantly, it really doesn't matter. They have both the key and the encrypted data. If someone hacks their system, the best encryption in the world won't help if the attacker steals both.

Why would they need the key? It says everything's encrypted/decrypted on the client. If they did encrypted-token indexing server-side, they wouldn't need to decrypt. Agreed that this scheme would eventually leak too much information.

Its unclear, but i think they are using client to mean their frontend server. They also say that the user recieves plaintext, and they integrate with cloud key provider services which would make no sense if they aren't using the key.

what is the point of this then? there's no actual secret then, LOL, are you sure?

What you are describing is basically a blind index (search for it, there are lots of good resources online). Blind indexes can be quite useful, but they have a number of limitations - the partial match issue as you point out, but also you cannot do range queries or sorting, and they leak some information (e.g. duplicates have the same index value). Blind indexes are most definitely not fully homomorphic encryption.

Right, but this service isn't advertising FHE.

That's false. From the FAQ on their homepage:

> Vaultree's proprietary encryption breakthroughs are in various encryption technologies traditionally limited to niche use cases. We finally enable users to process entirely encrypted data with Fully Homomorphic and Searchable Encryption (FHSE) and other technologies in the field. Explaining what they are would take all day, but here's a one-liner: FHSE enables data processing to be run directly on encrypted data in the same way as on plain text data.

well, they’re lying if it’s at any reasonable speed yet

FHE @ plain text speed?

Absolute bullshit.

> You choose the encryption standard in use for the database, from AES, DES, 3DES, Blowfish, Twofish, Skipjack, and more.

That seems very wrong ((as far as I know) those standards are not designed in such a way as to permit operations on their cyphertexts).

> Vaultree has achieved major breakthroughs in several encryption technologies, allowing organisations to process fully encrypted data at near plaintext speed and keep their data safe even in case of a leak.

That seems even wronger (security via obscurity at best).

> That seems very wrong ((as far as I know) those standards are not in any way designed in such a way as to permit operations on their cyphertexts).

Those standards are meaningless by themselves without specifying a mode (e.g. GCM, CTR, CBC, ECB, etc). A thing people sometimes try to do with them (no idea if this is what vaulttree is doing) is use some less secure mode that is determistic and do equality matching (this is almost always a bad idea and usually leaks way more than you would naively assume). For example, if you use ECB mode you can search as long as you are searching along block boundries.

https://www.microsoft.com/en-us/research/wp-content/uploads/... is an interesting paper about this sort of thing.

ECB should never be used under any circumstances. Library creators would do well to rename their functions along the lines of ECB_NEVER_USE_THIS_IS_NOT_SECURE.

In case it wasn't clear from my comment - i agree 100%

How I read it is that you specify which ways you will use a column and then VT will create the various encrypted columns to support this. Deterministic shared key for matches only. Ordered encryption for ranges and FHE for various calculations. The latter probably being quite slow. I don’t think they are rolling their own crypto, just combining a lot of existing algorithms in various ways.

I could see a use cases in either defense in depth and/or storing data in the cloud while having your keys somewhere else.

They're claiming to have made breakthroughs in several encryption technologies, not that they've figured out a clever way to glue some things together.

I could be wrong, but it smells like snake oil to me.

Let’s put it this way.. if they had actually cracked true FHE, they wouldn’t be a company anymore having been bought by the US government for billions of dollars.

Can't speak to Vaultree, but we (Blyss, YC W23, [0]) are also offering FHE as a service.

Our insight: if you focus on a specific problem, you can apply FHE much more efficiently and end up with practical speeds. (General-purpose FHE is still probably a ways off).

We are particularly interested in the problem of private information retrieval - fetching items from a large database, without revealing anything about your query to the server. Our server (open source! [1]) supports private queries against gigabytes of data in under a second.

That's a performance level that enables cool apps today. If you have any ideas for using FHE, do try out our SDK [1].

[0] https://blyss.dev

[1] https://github.com/blyssprivacy/sdk

Vaultree is deeply committed to advancing the field of data encryption while maintaining a responsible and transparent approach to security. Our innovations, particularly in searchable encryption, FHE and encrypted ML exemplify our dedication to creating practical and secure solutions.

For those interested in the technical specifics, Vaultree has developed a comprehensive approach to searchable encryption, detailed in our patent (EP4000213A1). This method enables efficient and secure search operations on encrypted data, ensuring that sensitive information remains protected without sacrificing usability. You can explore the full details of our patent [here](https://patents.google.com/patent/EP4000213A1/en?q=(Vaultree...).

Additionally, our work on Fully Homomorphic Encryption (FHE) represents a significant leap forward in the field. We've published our FHE scheme in the IACR ePrint archive, where it is accessible for review and further academic scrutiny. You can find the publication [here](https://eprint.iacr.org/2024/1105).

Moreover, we are actively working on encrypted Machine Learning (ML) implementations. To contribute to the broader community, we've open-sourced our VENumML library, which is based on Vaultree's FHE. This library aims to enable secure and private ML operations on encrypted data, pushing the boundaries of what is possible in privacy-preserving technologies.

Vaultree's commitment to innovation and responsible encryption practices ensures that we not only keep data secure but also advance the field with solutions that are both effective and practical for real-world applications.

Vaultree is deeply committed to advancing the field of data encryption while maintaining a responsible and transparent approach to security. Our innovations, particularly in searchable encryption, FHE and encrypted ML exemplify our dedication to creating practical and secure solutions.

For those interested in the technical specifics, Vaultree has developed a comprehensive approach to searchable encryption, detailed in our patent (EP4000213A1). This method enables efficient and secure search operations on encrypted data, ensuring that sensitive information remains protected without sacrificing usability. You can explore the full details of our patent here: https://patents.google.com/patent/EP4000213A1/en?q=(Vaultree...

Additionally, our work on Fully Homomorphic Encryption (FHE) represents a significant leap forward in the field. We've published our FHE scheme in the IACR ePrint archive, where it is accessible for review and further academic scrutiny. You can find the publications here: https://eprint.iacr.org/2024/1105 and https://eprint.iacr.org/2024/1622

Moreover, we are actively working on encrypted Machine Learning (ML) implementations. To contribute to the broader community, we've open-sourced our VENumML library, which is based on Vaultree's FHE. This library aims to enable secure and private ML operations on encrypted data, pushing the boundaries of what is possible in privacy-preserving technologies.

Vaultree's commitment to innovation and responsible encryption practices ensures that we not only keep data secure but also advance the field with solutions that are both effective and practical for real-world applications.