8 ms·

Has anyone used Vaultree[0]? Their product is FHE-as-a-Service and they claim "near plaintext speed". I've seen a few FHE posts roll across the front page rece

Has anyone used Vaultree[0]? Their product is FHE-as-a-Service and they claim "near plaintext speed". I've seen a few FHE posts roll across the front page recently and they all make me think of Vaultree because they sound like they've got it sorted. [0] https://www.vaultree.com/how-it-works/ https://www.vaultree.com/how-it-works/

whatshisface 4y ago
"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.
- hn_throwaway_99 4y ago
  Huh? How would you search on any encrypted fields?
  - KMag 4y ago
    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.
- admax88qqq 4y ago
  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.
  - amadvance 4y ago
    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 https://news.ycombinator.com/item?id=31668814
- teraflop 4y ago
  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.
  - whatshisface 4y ago
    Those kinds of problems have never stopped any company from offering a service with a lot of nice graphics on the home page.
  - 5ersi 4y ago
    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.
    - kientuong114 4y ago
      How would you run queries over that?
hn_throwaway_99 4y ago
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-making-encrypted-personal-data-searchable-b26bce99ce7c https://medium.com/@joshuakelly/blind-indexes-in-3-minutes-m...
- bawolff 4y ago
  > "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 ;)
- fragmede 4y ago
  It's up to them to define "near", but I'd consider https://spiralwiki.com/ https://spiralwiki.com/ (Samir Menon and Prof. David Wu at UT Austin) "nearly" usable compared to regular wikipedia.
bahorn 4y ago
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_encryption https://en.wikipedia.org/wiki/Searchable_symmetric_encryptio...
smoldesu 4y ago
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.
bawolff 4y ago
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.
- pmarreck 4y ago
  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?
  - Dylan16807 4y ago
    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.
  - bawolff 4y ago
    > 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.
yarg 4y ago
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 in any way 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).
- bawolff 4y ago
  > 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/2017/02/edb.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... is an interesting paper about this sort of thing.
  - yarg 4y ago
    https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.jpg https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb....
  - l33t233372 4y ago
    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.
    - bawolff 4y ago
      In case it wasn't clear from my comment - i agree 100%
lwansbrough 4y ago
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.
blyss 4y ago
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 https://blyss.dev [1] https://github.com/blyssprivacy/sdk https://github.com/blyssprivacy/sdk
deleted 2y ago
[deleted]
Vaultree2020 2y ago
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)&oq=Vaultree 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 https://eprint.iacr.org/2024/1105 and https://eprint.iacr.org/2024/1622 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.

whatshisface 4y ago

"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.

hn_throwaway_99 4y ago
Huh? How would you search on any encrypted fields?
- KMag 4y ago
  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.
admax88qqq 4y ago
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.
- amadvance 4y ago
  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 https://news.ycombinator.com/item?id=31668814
teraflop 4y ago
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.
- whatshisface 4y ago
  Those kinds of problems have never stopped any company from offering a service with a lot of nice graphics on the home page.
- 5ersi 4y ago
  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.
  - kientuong114 4y ago
    How would you run queries over that?

hn_throwaway_99 4y ago

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-making-encrypted-personal-data-searchable-b26bce99ce7c https://medium.com/@joshuakelly/blind-indexes-in-3-minutes-m...

bawolff 4y ago
> "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 ;)
fragmede 4y ago
It's up to them to define "near", but I'd consider https://spiralwiki.com/ https://spiralwiki.com/ (Samir Menon and Prof. David Wu at UT Austin) "nearly" usable compared to regular wikipedia.

bahorn 4y ago

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_encryption https://en.wikipedia.org/wiki/Searchable_symmetric_encryptio...

smoldesu 4y ago

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.

bawolff 4y ago

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.

pmarreck 4y ago
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?
- Dylan16807 4y ago
  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.
- bawolff 4y ago
  > 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.

yarg 4y ago

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 in any way 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).

bawolff 4y ago
> 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/2017/02/edb.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/... is an interesting paper about this sort of thing.
- yarg 4y ago
  https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.jpg https://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb....
- l33t233372 4y ago
  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.
  - bawolff 4y ago
    In case it wasn't clear from my comment - i agree 100%

lwansbrough 4y ago

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.

blyss 4y ago

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 https://blyss.dev [1] https://github.com/blyssprivacy/sdk https://github.com/blyssprivacy/sdk

deleted 2y ago

[deleted]

Vaultree2020 2y ago

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)&oq=Vaultree 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 https://eprint.iacr.org/2024/1105 and https://eprint.iacr.org/2024/1622 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.