3 ms·

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

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.
- pmarreck 4y ago
  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.
  - bawolff 4y ago
    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.
    - pmarreck 4y ago
      what is the point of this then? there's no actual secret then, LOL, are you sure? If that's the case it simply moves "the need to trust the DB host" to "the need to trust the encrypt/decrypt intermediary" (literally a MITM, LOL)
hn_throwaway_99 4y ago
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.
- pmarreck 4y ago
  Right, but this service isn't advertising FHE.
  - hn_throwaway_99 4y ago
    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.
    - pmarreck 4y ago
      well, they’re lying if it’s at any reasonable speed yet

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.

pmarreck 4y ago
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.
- bawolff 4y ago
  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.
  - pmarreck 4y ago
    what is the point of this then? there's no actual secret then, LOL, are you sure? If that's the case it simply moves "the need to trust the DB host" to "the need to trust the encrypt/decrypt intermediary" (literally a MITM, LOL)

hn_throwaway_99 4y ago

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.

pmarreck 4y ago
Right, but this service isn't advertising FHE.
- hn_throwaway_99 4y ago
  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.
  - pmarreck 4y ago
    well, they’re lying if it’s at any reasonable speed yet