Search Over Encrypted Data I'm doing a research about how to search over encrypted data as the title said. And, I saw cryptDB used a cryptographic scheme from Song et.al's article Practical Techniques for Searches on Encrypted Data to search for words on encrypted data. But why they don't use DET encryption for each word and to search for a word just encrypt a word and compare it?
If you encrypt the words with the ECB mode then it will reveal information which we call frequency attack. The attacker can see which words are repeating among the rows and try to extract information especially if the attackers have some knowledge of the data contained in the database. 

We can see this in a small SEARCH column if encrypted with ECB mode;

| ID  |...| SEARCH                                         |
| x01 |...| 0xF41, 0x650, 0x086, 0x331 ....                |
| x02 |...| 0xF41, 0x165, 0x086, 0x63f, 0x754 ....         |
| x03 |...| 0x650, 0x331, 0x1E6, 0x12f, 0x004 ....         |


As you can see, if you use the ECB mode directly, you can extract information from the SEARCH rows. Using ECB column in CryptDB is your choice. If you think that the data is vulnerable to attack, don't use the ECB mode. 

Instead of using ECB, they choose to Song's work and modified as;

They split the words with standard delimiters, removed the repetitions, randomly permuted the repeated words, padded each word into the same size then encrypted.

They claim that their SEARCH nearly as secure as their RND mode, CBC mode with randomized IV for each encryption. They also claim that DBMS server cannot distinguish whether a word repeats in multiple rows and it only leaks the number of distinct words by comparing the size of RND column and SEARCH column.

It is not clear from their article that how this effect the performance. Actually, it is clear that the encryptions with different keys for each row are not performed on the Database. The whole burden of the system is based on the Proxy-Server, and the overhead to the proxy server is not measured for the article.