Search by encrypted information. How to implement?

Question

Encryption

Greetings!

There is data that is encrypted on the client side with the AES algorithm. The data is then stored on the server.

We cannot store data in clear text on the server, such a privacy policy.

How can you organize a search on this data?

Take hash (keywords/tags) and search by it?

Thank you!

Answer 1

it's impossible. That's the point of encryption.

Answer 2

Keys at the client — search on the client. That is, in any case, you have to pull all the data on the client.

Answer 3

If the server does not participate in encryption at all, then how you are going to search there at all is not very clear ... Theoretically, you can create indexes for plain text, and store the text itself encrypted. But it seems like there is little benefit from this in terms of security, and it must be transferred openly to the server.

Answer 4

AES is resistant to this type of crypto attacks. Without changing the encryption algorithm in any way.
Well, or encrypt either not all, or in parts. But then the privacy policy...

Answer 5

I tried to solve a similar problem:
- data is stored on the server, encrypted on the client, the server does not even know about the encryption algorithm, although in general the algorithm is symmetric, the key is one and private as a result
- it was necessary to implement AJAX auto-completion (strings are relatively short, full name in general)
So far, I got out like this:
- when saving the field, the client encrypts the data and puts it in the main table
- additionally for each substring (the first letter, the first two letters, the first three letters, ..., all the full name) a hash is formed (with a salt) and placed in another table linked to main (many hashes for each entry in main)
- when a user enters a new entry, the client sends a hash of the entered letters to the server, which issues encrypted entries for which this hash exists (for example, all entries that start with 'A')
- the client decrypts the entries, uniques them (there are duplicates even on a relatively small base , in theory there are a lot of full namesakes) and shows the user some of them (in initial letters, show everything if it’s real, but it makes no sense)
Global drawback:
- a big load on the client, when you need to decrypt about a couple of hundred records (with a database of 3000 people) after entering the first letter - in JavaScript this is, to put it mildly, not fast, generating about 20-40 hashes while maintaining a trifle against this background, like a few extra kilobytes per hash entry. What will happen when thousands of records are returned for decryption - it’s scary to think, you need to think about how to limit and uniqueize records on the server and how to call native encryption libraries like mhash and mcrypt from the JS browser

Answer 6

Use Microsoft SQL Server 2008 with encryption enabled.

Answer 7

Well, let the client, together with the encrypted data, create and transmit an unencrypted array of words to build an index for this document. All sensitive data is discarded (well, numbers, passwords, easily regexp), leaving only a meaningless set of simple words sorted alphabetically.
Hashing every word is pointless because it doesn't improve security: it's easy to take the hashes of a large arbitrary set of words and compare them to the entries in an existing index.