Review for Paper: 40-CryptDB: Processing Queries on an Encrypted Database

Review 1

When database servers are compromised, either by malicious administrators or by outside hackers, the clients’ data can be exposed. One way to avoid this is to store encrypted data in the database, and when users query the database, ship the data to them so they can decrypt it and evaluate queries locally. This approach is too costly, however, because it requires a large amount of data shipping and client-side computation. It would be better to store encrypted data in the database server, while still allowing the server to compute query results, and ship the answers to the user for decryption.

CryptDB is a system that aims to keep data as fully encrypted as possible in the database server, while allowing the server to process client queries on encrypted data. CryptDB does this by storing multiple encrypted versions of each column, one for each way that users might select or join on the column’s values. For example, CryptDB uses a different form of encryption for string comparisons from the encryption for numerical comparisons.

Each encryption type is stored as an “onion,” where plaintext data is first encrypted in the form that allows most computation but leaks most information, then more and more up to a randomized encryption. At first, the database server sees very little information due to the randomized outer encryption layer. If the server needs to select for number values that are greater than 5, for example, the data will be decrypted to the Order-Preserving Encryption layer first, revealing a bit more information to the server but allowing the server to process the query.

One drawback of CryptDB is that it requires considerable space overhead to store multiple copies of all columns, one per onion, and with some onions being larger than the base data. In addition, the throughput of CryptDB is about one fourth less than that of the base database (MySQL) for the TPC-C transactional workload. The throughput is worst for queries that manipulate homomorphically encrypted values, such as sums. One more problem with CryptDB is that it does not support some SQL queries, such as queries on substrings or date components. The authors note that if tables were augmented with the appropriate substrings or date parts, CryptDB could handle queries on those new columns.



Review 2

The paper deals with the problem of mitigating data leaks from databases using CryptDB which processes queries on an encrypted database. Online applications are vulnerable to theft of sensitive information by attackers and malicious DBAs breaching confidentiality of the users. To protect the data from such an attack, authors propose to use a database known as CryptDB.

The database in question is encrypted by CryptDB using different keys and encryptions for different columns and users leaving nothing in plain text. It uses SQL-aware encryption, adjustable query-based encryption and chain encryption keys to user passwords. SQL-aware encryption uses different encryptions for different columns and operations in SQL-aware encryption. In adjustable query-based encryption, re-encryption is done to the required format. In chain encryption keys to user passwords, different users’ data has different encryption keys dealing with SQL injection as well. CryptDB’s architecture consists of an application server (handling normal front web page, user login and key setup to database proxy), CryptDB proxy server (handling active keys and annotation of schema) and DBMS server (normal DBMS with encrypted data, user defined functions to encrypt and encrypted key table). If a DBMS server is compromised, it won’t be a problem since a server cannot compute the encrypted result. If all the servers are compromised, data of inactive user’s key is unavailable. But this has its limitations. Both computation and comparison on same column is not possible and multi-principal data can not be encrypted to different format.

The authors are comprehensive in providing their solution of using CryptDB which improves data security without changing DBMS or any application. It prevents data leaking even when the server is totally compromised. The argument is supported by microbenchmark results as well.

CryptDB has a performance overhead of about 26% for TPC-C which is relatively high for large databases. Frequently re-writing data takes much time. Data repair takes even more time leading to high computation overhead.



Review 3

This paper presents a new system called CryptDB, which is a practical system that explores an intermediate design point to provide confidentiality for applications that use DBMS. In short, CryptDB is a practical system that can execute a wide range of SQL queries over encrypted data. CryptDB provides confidentiality in 2 main threats, passive adversary on DBMS server and arbitrary compromise to application server and DBMS. It uses SQL-aware adjustable encryption with multiple onions and requires no changes to the internals of DBMS. This paper first gives an overview about threat models. Second, it describes how to execute SQL queries on encrypted data. Then it shows an implementation on top of mysql proxy, as well as an experiment evaluation. Finally, it discusses related and future work.

The problem here is that theft of private information in DMBS has been a significant problem for online applications, however, current solutions have some shortcomings such as many orders of magnitude slower with encryption. Many information need to be protected, for example medical records, credit card number and social security numbers. There has been many attacks, including unauthorized access to servers, snooping on private data, and physical attack on servers (disk and memory). General solution is to provide encrypted data, but full homomorphic encryption makes it much slower than plaintext computation. Therefore, in this paper, it presents a faster and secure system called CryptDB.

The major contribution of the paper is that it provides detail design for CryptDB. By doing performance evaluation on a traditional benchmark TPC-C, it shows that CryptDB can provide security with only 26% throughput reduce. Also, it does not require any changes in the internal of DBMS which makes it easy to add CryptDB. Here we will summarize key elements of CryptDB:

1. sensitive data is not available in plaintext at DBMS server
2. no leaks on data content if application requests no relational predicate on a column
3. no reveal on actual values if application requests equality checks on a column
4. reveal the order of elements if application request order checks on a column

One interesting observation: this paper is very innovative, and idea of adding a proxy is interesting. It can provide guarantees for any threats who gain access to the DMBS server, and most importantly it does not decrease throughput a lot. One possible weakness is that it does not guarantee for logged-in users.


Review 4

This paper focuses on keeping the data stored in a database private and secure. The author see encryption as the way to accomplish this. However, there are multiple different ways to achieve data encryption. You could, like Oracle does, encrypt the data stored on disk, and then decode it at query time. However, this requires all the servers to have decryption keys, and it exposes the data at query time - leaving it vulnerable. What we would really like is a system that lets us run our queries on the data, while the data itself is still encrypted. This is what CryptDB hopes to achieve.

In the face of constant hacks and data breach, it is easy to see why this is important. If Sony had encrypted their data, they would not have lost the information of 77 million customers. Target, Zappos, eBay, many separate US federal agencies, Adobe, Home depot - the list goes on. Encrypting their database may not have prevented these breaches, but it would have mad discern any information for the stolen data incredibly difficult.

CryptDB uses several layers of encryption - so called onion layers. These layers are only peeled back as needed. Each layer is implemented using a different type of encryption - some encryption that reveals nothing about the data, some the preserve order, and some that allow for keyword matching. Using these various different layers, the queries can execute removing only the layers that they need, so that they can determine the result of the operations - equal, not equal, less than, greater than, keyword match, etc. All users have their own keys, based on their password, that gives them access to some portion of the data. These can them be chained to share data.

One thing I thought was really cool about CryptDB is that is was built decoupled from the rest of a DBMS, so can easily be added into an existing system. All that it requires is that the DBMS support UDF's, and the system should work. The authors already have it working with PostgresSQL and MySQL.

The only downside I can see is that it can't support all queries and columns yet. In their tests, they report they can support 99.5% of the columns from MIT's MySQL DB.
It don't see the cost of encrypting and decrypting as a negative - its a tradeoff for protecting your data, and its worth it!.


Review 5

Problem and solution:
The problem proposed in the paper is the data leak. In online applications, data theft happens on a nearly daily basis and results in the big problem of privacy leak. There are mainly three reasons for the leak. One is that vulnerable softwares provide the possibility for adversaries to gain the unauthorized access to servers and get the stored data. Another is the database or system administrators are so curious that they see the private data themselves. The other reason is the attackers attack the server via physical access and steal the data. Encrypting the sensitive data on the server protects the privacy, while it decreases the performance greatly if the encrypted data should be decrypted to plaintext in every execution. The solution is to enable the server to compute over encrypted data without decrypting it and produce results in an encrypted form as well. CryptDB is the intermediate system that can provide the high performance confidentiality for online applications over their DBMS. It can execute a large quantity of SQL queries over encrypted data without requiring any changes to the internals of the DBMS server and the result is decryptable only by the trusted client. It can work with most SQL database systems with very modest overhead. It means that the system is practical in actual use.

Main contribution:
The main contribution of CryptDB is that it provides a way to execute SQL queries over encrypted data so that the privacy of data could be protected without sacrificing too much performance. It uses several different encryption methods (RND, DET, OPE, HOM, JOIN, SEARCH) to achieve the most secure encryption schemes. Since the query is not always known in advance, the encryption scheme is adaptive and can dynamically adjust encryption strategies. CryptDB uses the onions method to encrypt the data in layers for increasingly stronger encryption.

Weakness:
Though the idea of CryptDB is quite interesting, it still has some weakness. One is that since the data stored are encrypted and can only be decrypted with the key of trusted client, all the data may be unreadable if the key is lost.


Review 6

This paper introduces CryptDB, a solution for information security on DBMS. It focuses on the threat of compromised DBMS server, which can be caused by attacker gaining control on the DBMS server or curious administrator. CryptDB adds a proxy layer above the DBMS and set up some UDFs to manage data of encryption. In general, it implements onion encryption for the data and only does the necessary type of decryption under the corresponding operations. For each query from the client, it translate the original queries into queries for the encryption data and sends it to the underlying DBMS.DBMS may do the necessary decryption using UDFs, query on the encrypted data and sends it back. The proxy the decrypts the result and sends to client. In CryptDB, the DBMS server can only operates on the encrypted data, which guarantees information security. In addition, the onion encryption and SQL-aware and adjustable encryption guarantees the efficiency of the encrypted DBMS.
Strengths:
CryptDB provide efficiency operations for the encrypted data. It requires less overhead in the normal operation for the encrypted data. To achieve this, CryptDB dynamically changes the type of encryption based on the query workload to choose the fast and secure enough operations on the data.

Drawbacks:
The index might not be efficient To support index, the encryption of that column should be OPE. This kind of limits the security. In addition, if there are multi-dimension indexes, the encryption of indexes become complex and makes the insert and delete even more expensive.


Review 7

This paper discusses CryptDB which is framework that allows a database to efficiently handle queries on encrypted data without requiring the data to be fully decoded. Furthermore, CryptDB allows for the sharing of user data if necessary. The basic idea is to encrypt data in increasingly stronger layers of security, with the outermost layer being the strongest. As queries are made against the database, a middleware proxy containing a secret key encrypts or decrypts data. If certain types of conditions need to be evaluated such as equality or ordering conditions, the proxy will peel off layers of security to allow the database to be able to perform the computations. However, the data is never exposed in plaintext on the database. The overhead of CryptDB is only about 26% over an OLPT workload. The authors consider this to be a reasonable overhead due to the gain in confidentiality.

I think one of the limitations of CryptDB is the ability for the database to make optimizations on queries. Normally, a database will have a full view of the information stored in it so it can create indices and create materialized views. One general problem for databases is when workloads change. After executing a certain type of workload, a database will begin to adapt to the workload and become more efficient at processing it. OLTP workloads are a good representation of this where the same types of queries can be expected to repeat. However, if the workload changes the indices and views a database created may no longer be relevant. In the case of CryptDB, the rebuilding cost is very high since the encryption levels of the data may change. I think I would have liked to see the authors of the paper evaluate CryptDB on a changing workload to see the overhead.

An interesting question is whether CryptDB also results in anonymization of data. I think it would since it uses multiple forms of encryption with the last layer using AES. I think this would break the probability distribution patters of the data. If this is the case, then CryptDB not only provides a framework for computation over encrypted data, but also over anonymized data that could be extended. What if instead of just hiding the columns, the actual data values were encrypted as well before being published?


Review 8

Data privacy is an important issue for some DBMSs. It would be ideal if a DBMS can provide efficient service while preserving complete data privacy -- by storing only encrypted data on servers. However, computations over encrypted data can be extremely slow comparing to computations over plaintexts. This paper presents CryptDB, a practical DBMS that can perform SQL queries over encrypted data with a practical computation efficiency. The key idea behind this practical DBMS is that most SQL queries use a small set of operators and they focus on optimizing such operators over encrypted data.

CryptDB uses a MySQL back-end and requires no changes to the internals of the DBMS server. The query processing of CryptDB involves: proxy replaces the components using master key MK and other encryption scheme, adjust encryption layers if the DBMS server is permitted, proxy sends the encrypted query to the server, server executes the query, proxy decrypts the results and returns the results to applications.

CryptDB encrypts data using different encryption schemes, including a number of existing cryptosystems and a new cryptographic primitive for joins. This paper goes through difference schemes and explains the security properties required and their implementations.

The major contributions of this paper include:
1. It presents the first practical system that is able to process queries (and support most SQL queries) over encrypted database.
2. It uses onions of encryption that compactly store multiple ciphertexts within each other in the database and avoid revealing weaker encryption schemes when they are not needed.
ions are a novel way to
3. CryptDB requires no changes to the internals of the DBMS.
4. Its experimental results show that CryptDB can handles a wide range of queries commonly observed in practice, with a modest performance overhead.


Data privacy is an important issue for some DBMSs. It would be ideal if a DBMS can provide efficient service while preserving complete data privacy -- by storing only encrypted data on servers. However, computations over encrypted data can be extremely slow comparing to computations over plaintexts. This paper presents CryptDB, a practical DBMS that can perform SQL queries over encrypted data with a practical computation efficiency. The key idea behind this practical DBMS is that most SQL queries use a small set of operators and they focus on optimizing such operators over encrypted data.

CryptDB uses a MySQL back-end and requires no changes to the internals of the DBMS server. The query processing of CryptDB involves: proxy replaces the components using master key MK and other encryption scheme, adjust encryption layers if the DBMS server is permitted, proxy sends the encrypted query to the server, server executes the query, proxy decrypts the results and returns the results to applications.

CryptDB encrypts data using different encryption schemes, including a number of existing cryptosystems and a new cryptographic primitive for joins. This paper goes through difference schemes and explains the security properties required and their implementations.

The major contributions of this paper include:
1. It presents the first practical system that is able to process queries (and support most SQL queries) over encrypted database.
2. It uses onions of encryption that compactly store multiple ciphertexts within each other in the database and avoid revealing weaker encryption schemes when they are not needed.
ions are a novel way to
3. CryptDB requires no changes to the internals of the DBMS.
4. Its experimental results show that CryptDB can handles a wide range of queries commonly observed in practice, with a modest performance overhead.

Some drawbacks of this paper include:
The experiments in this paper assumes that all workloads fit in the server’s RAM. However, when the workload does not fit into the RAM, which is more often the case, the performance difference would be greater since CryptDB requires more additional work than MySQL


Review 9

Motivation for CryptDB:

CryptDB is able to execute a wide range of SQL queries over encrypted data, because it can efficient support a set of well-defined operators over encrypted data. Enabling a server to compute over encrypted data that only the trusted client can decrypt is important because we want to protect sensitive data (such as gaming profiles that include credit card information) but also perform computations on the data. CryptDB addresses the threats from adversaries who gain access to the DBMS server and tries to learn private data, such as financial statements and health records, by exploiting some vulnerability in accessing the DB server, when the DB is outsourced to a public cloud or other external organization, or when the DBMS is administered by an untrustworthy database administrator. CryptDB also protects against the attacker who gets total control of both the DBMS servers and the application by protecting the identity of users logged out of the application, but cannot ensure protection for users logged in. CryptDB works with mot standard SQL DBMSs and require no changes in the internals of the DBMS server. CryptDB has little overhead (compared with MySQL without encryption, throughput reduces by 26% for queries on the TPC-C benchmark, and by 14.5% on phpBB) and supports most operations over encrypted data (99.5% of 128,840 columns in the query trace).

Details on CryptDB:

In order to execute queries on encrypted data, CryptDB restricts the server to computing only the functions required to process authorized queries and performing the query as it would on an unencrypted database. The proxy has to allow the DBMS server to determine relationships among data items necessary for query processing, so that if the DBMS is performing a GROUP BY on a column, for example, the DBMS server can determine when items in the column are equivalent, but no what the actual values are. CryptDB does not reveal more relations between tuples than necessary. For example, when the query contains GROUP BY, the server will not know the order of the column, or information on other columns. For ORDER BY, MAX, or MIN, CryptDB will show the order, but not otherwise. CryptDB utilizes SQL-aware encryption, which uses known encryption schemes for equality, additions, order checks, and joins to encrypt data items in a way that allows the DBMS to execute on transformed data. CryptDB also uses adjustable query-based encryption which makes any data item fit different operations by adjusting the SQL-aware encryption scheme. This is done with the onions of encryption, which compactly store multiple cipher texts within each other in the database, avoiding weaker encryption schemes when not needed. The properties provided by CryptDB are that sensitive data is never available in plaintext at the DBMS server, no data leaks if the application requests no relational predicate filtering on a column, the proxy reveals which items repeat without revealing the values when equality checks are requested, and the proxy reveals order of the elements in the column if the application requests order checks on a column.

The four steps to processing a query in CryptDB are: 1. A query is issued by the application, which the proxy first takes and rewrites by anonymizing the table and column names and using the master key to encrypt each constant in the query with the most suited encryption scheme for the operation. 2. The proxy checks if the DBMS server should be given keys to adjust encryption layers before executing the query and issues UPDATE query if it does to invoke a user defined function that adjusts the encryption layer of the target columns. 3. The encrypted query is sent from the proxy to the server, where it is then executed. 4. An encrypted query result is returned from the server to the proxy, which is then decrypted by the proxy and returned to the application. One encryption method in CryptDB is Random (RND), which provides maximum security, but does not allow any computation on the ciphertext. Deterministic (DET) are a pseudo-random permutation that is deterministically generating the same ciphertext for the same plaintext, allowing servers to learn the correspondence between encrypted values and same data value and perform equality checks for selects, equality joins, GROUPBY, COUNT, DISTINCTIVE, etc. Order-preserving encryption (OPE), which enables the server to get the order of relations between encrypted data items without revealing the value, can leak half the data bits at worst case and should only be used when the order is requested. Homomorphic encryption (HOM) lets the server perform computations on encrypted data with the final result decrypted at the proxy and is as secure as RND. HOM is slow, but efficient for certain operations. Join (JOIN and OPE-JOIN) is needed to allow equality join between two columns since different keys for DET are used to prevent correlations between columns. OPE-JOIN enables joins with ordered relations. Word search (SEARCH) is used to perform searches on encrypted text and is as secure as RND.

Strengths of the paper:

I enjoyed the paper because it was written in a way that allowed the reader to stay engaged and intuitively follow along. It was interesting to read the comprehensive discussion on the how CryptDB enables computations over encrypted data (with RND, DET, OPE, etc). The idea of encrypting data items in onions to allow layers of increasingly stronger encryption was interesting and clever to me because it had not occurred to me to add on and take away levels of encryption as needed to optimize both security and computational ability.

Limitations of the paper:

I would have liked to see the paper address whether information that is valuable even without identifying the person, such as credit card numbers, is treated with additional security. How is this type of information treated differently from data that is unacceptable only if linked to a person, such as medical attributes? The paper also mentions how OPE can leak half the data bits in the worst case. I would've liked to see the paper be clearer about how exactly the order is leaked by OPE and what is being done to mitigate the worst case.



Review 10

CryptDB is introduced in this paper to solve problems relating to the practicality of using encrypted data in a database management system to be queried with SQL. SQL-aware encryption is used to support these operations and provides strong confidentiality without requiring changes to the DBMS system. The paper looks at two types of threats. These are compromises to the database by a passive adversary and compromises to the application. The authors provide evaluation in terms of the support for applications, level of security provided, and execution time.

This paper starts by motivating its approach by relevant database attacks from around the time of publication in 2012. They mention the theft of private information and the need for encrypted information that can be practically used by database systems that support the same functionality already in use. They provide a detailed threat model. The SQL-aware encryption allows several different methods of encryption. These include random, deterministic, order-preserving, homomorphic, join, and word search. Here there is a tradeoff between security and functionality that is important to note. For instance, the order-preserving encryption allows support for sorting and range query type operations but reveals the order of data in the database. The evaluation of the paper includes five applications with a variety of operations. The important functionality implemented for this paper and the thorough evaluation are strengths of the paper.

There are a few drawbacks of the paper. Although they claim their approach is practical the performance hit from encrypting and decrypting data is not negligible. There are applications and systems that would be much less functional with this type of implementation. In figure 5 that the only aggregate query is sum and that it has the biggest performance hit, with almost half the throughput. The evaluation is a little lacking in this area even though they included so many different applications. There are types of applications that will require analysis of data using aggregate functions for which this type of system may not be appropriate. Future work could shed more light on this area.



Review 11

Part 1: Overview
This paper presents a securing database called CryptDB which provides confidentiality for applications. It is actually a middleware layer wrapper which receive queries and secure them and then forward them to the server. CryptDB faces two threats, one is an adversary who gains access to the DBMS server and tries to learn private data, the other one is an adversary who gains complete control of the application and the DBMS servers. There would be several kinds of threats. The first one is DBMS server compromise. In this case, CryptDB provides confidentiality in the face of an attacker with full read access to the data stored in the DBMS server. The attacker should passive. The second one is arbitrary threats. The reason behind is that an adversary corrupting the proxy can now get access to the master key used to encrypt the entire database.

Randomly encrypt everything is the best way to secure information however would lead to too much overhead when doing updates and migration of data. In other words, computations on RND based databases would have poor efficiency. Deterministic (DET) encryption allows doing computation on the encrypted data, by trading off some security. Order preserving encryption (OPE) would be gaining the lower security one but would provide much efficiency for the computation part. The worst security is provided by the homomorphic encryption (HOM).

Part 2: Contributions
Thanks to the fact that most SQL queries use a small set of well-defined operators, each of which we are able to support efficiently over encrypted data. This provide the opportunity to implement encrypted execution. CryptDB is the first practical system that can execute a wide range of SQL queries over encrypted data.

Part 3: Drawbacks
The logged in user could manage to see the shared data left by some logged out user. Which in some cases make sense however would be a threat in some history crucial applications.

CryptDB, as a column oriented database, would hate updates as they need to actually scan the whole databases.



Review 12

The paper discusses about CryptDB, a system that execute SQL queries over encrypted data. CryptDB addressed two kind of security threats model. The first threat model is an adversary who gains access to the DBMS server and tries to learn private data. Such kind of threats can arise when an attacker exploits some vulnerability that allows it to directly get to the DBMS server. In this case, CryptDB can prevent the attackers from learning private data even though it get into the system. The other threat model discussed in the paper is an attacker who gain complete control of the application and the DBMS server. In this case, CryptDB protects the privacy of the data of the users who not logged-in during the attack. However, the confidentiality of users already logged-in can be accessed by the adversary.

CryptDB stores a secret master key and the database schema. The DBMS server sees an anonymized schema and encrypted user data from CryptDB. The server uses user-defined functions, received from CryptDB, to compute on encrypted data. CryptDB incorporates two technique for encryption. The first technique is SQL-aware encryption, which exploit the fact that most SQL queries being made up of well-defined sets of operators like aggregates and joins. The second technique is called adjustable query-based encryption. The goal of CryptDB is to use the most secure encryption schemes (from RND, DET, etc) that make executing the requested queries possible. In this technique, CryptDB start encrypting using the strongest encryption scheme and dynamically add/remove layers of encryption based on the kind of queries received from the users. CryptDB encrypts each data item in one or more onions i.e each value is dressed in layers of increasingly stronger encryption. Each layer of each onion enables a certain class of computation. Once CryptDB makes sure the correct onion layers is set in the DBMS for a particular query request, it replaces the query with the corresponding encrypted query and user defined functions and issued to start the query execution. The DBMS perform the query execution on a totally encrypted queries and user data..

The main strength of the paper is it addresses an important class of problem. With the rise of cloud computing and online services like shopping, privacy on online applications is increasing becoming important. I like the fact that CryptDB allows to secure sensitive information of the users even while the servers are compromised.

The main limitation of CryptDB is that computation over encrypted data have more computation overhead than unencrypted data. With the exponential growth of online data and complex operations on this data, itt will become a challenge to absorb the computational overhead of CryptDB-like services. In addition, the kind of operations supported by CryptDB are limited as performing operation in encrypted data is less flexible. For example, CryptDB cannot support order comparison with a summation operation. Another limitation is that CryptDB does not hide the overall table structure, the number of rows, types of columns and the approximate size of data in bytes. It would be great if future works addressed to hide these information as they could exploited by an adversary .



Review 13

===OVERVIEW===
Protecting private information in a database is a important problem. Encrypting all the data is one approach, but in order to do computation and analysis on the data set, you have to have some sort of trusted client to download all the data and perform the computation, which is bad because that basically treats database as a pure storage. Ideally, one might want the data to be encrypted and at same time to perform computation on these encrypted data. Fully homomorphic encryption enable the server to compute arbitrary functions over encrypted data, while providing excellent confidentiality
guarantees. However, it is slow. In this paper, the author introduce CryptDB, a practical system that explores an intermediate design point to provide confidentiality for applications that use database management systems.

===KEY CONTRIBUTION===
CryptDB is the key contribution of this paper. It is the first practical system that can execute a wide range of SQL queries on encrypted data. In the face of two significant threats, the database is able to provides a strong level of confidentiality with a modest performance overhead.

===STRENGTH===
The paper address a very important problem. People not only want the data to be secure, but also want the performance degradation to be small to have that extra security. CrypedDB make that. The design of the system is novel and the experiments clearly shows that the database undertake two serious security attack.

===WEAKNESS===
Not all database can afford 0.6 ms latency on each query. The paper doesn't mention where the encrypted data is not necessary. In another word, the use case of the CryptDB is vague.


Review 14

This paper introduced CryptDB, a database that support SQL queries on encrypted data.
CryptDB is designed to protect user data from anyone else except people who need this data to do their job, and this includes the DB administrator and other adversaries. To achieve this goal, all data in DBMS server is encrypted. One of the most important concepts in this paper is onions of encryption. Every piece of data is encrypted multiple times. A Stronger encryption gives better privacy but support less type of operations. That’s why strongest encryption is done at the outermost layer. Each time a query is executed, related data is decrypted to outermost layer that supports the type of operations needed.
A trusted proxy sits in between DBMS server and user. Each time user wants to execute a query, this proxy rewrites the query and send this query to DBMS server, along with the keys needed. At the DBMS server, corresponding data is decrypted and results are returned to user. Also CryptDB hides the column names for individual tables so that no one can infer the data by looking at the encrypted text.

Contributions:
This paper proposed this interesting idea of performing SQL over encrypted data. And they come up with this onion of encryption to support different SQL queries. I think what they did is really brilliant.

Weakness:
The proxy machine stored all keys used by DBMS system, so this machine can become a weak point in this whole system. Another problem is who will administrate the trusted proxy machine.



Review 15

CryptDB is a database that encrypts the data that is present in the database such that even the DBMS does not have access to raw data and only the user with a specific level of access to a specific portion of the data would have access to the same. One of their key selling points is the fact that they can represent a wide range of SQL queries over encrypted data. Based on their results from the MIT MySQL service results, it is pretty impressive.

The authors begin with the idea where an attacker either figures and exploits a given vulnerability in the database and is able to mess with the same. The worse situation is when an adversary gains complete control of the application and the database servers, the authors want to prevent the adversary from having access to the data even at this level of breaking in to the system. They use a cryptdb proxy that encrypts and decrypts the data and changes the query operators to be compatible with the security schemes. They have two specific techniques: SQL-aware encryption techniques and adjustable query-based encryption. Their SQL-aware encryption works on the basis on typical queries whose responses can be obtained based on specific kinds of encryption method. For eg, they use random to provide maximum security which could be used if you want to get all the possible data in a table. Since no two values map to the same cipher text, there would be no way of breaking it through the ipher text. The Deterministic encryption is used to encode equality clauses and order-preserving encryption is used for queries that have order by clause in them. The adjustable query-based execution ensures that these values are encrypted in layers like an onion so that they can be peeled, or rather decrypted based on the query request.

One of the major advantages of this system was that in order to be used, neither the application nor the database system need to be modified. The SQL aware encryption methods were a definite advantage since they really seem logical in terms of the fact that, for these given operators, you actually would not need to see the actual data to perform the operation. Another plus was their layering mechanism that keeps protection as their major goal and that the layers are peeled off only as required by the query.

One of the disadvantages or possible weaknesses that could come from the peeling off the layers is that, since each lower level corresponds to lower security, equality queries or ordering queries could pose a risk for attack. Another point that blaringly comes across is that security comes at the cost of performance, so there needs to be a tradeoff between level of security required and performance required. Also, even though they specify that the CryptDB proxy is trustworthy, I guess there is a chance that if that is compromised, the attacker would have access to the decrypted data.

Overall, this really comes across as a DB that is practical for an applications and companies such as banks and credit card details where data security is highly necessary.




Review 16

CryptDB: Processing Queries on an Encrypted Database paper review

In this paper, the author mainly introduced the problem that, sensitive data can leak from online data repositories for a variety of reasons, including snooping Database Administrators (DBAs) and compromise from attackers. A possible approach to reduce the damage caused by server compromises is to encrypt all sensitive data stored on the servers. But, several important applications do not lend themselves to this approach. In this paper, the author proposed a new technique of using proxy encryption using CryptDB, A system that explores an intermediate design point to provide confidentiality for applications that use database management systems. The author mainly discusses about confidentiality of information flowing between application and database servers, but not any form of information security like integrity and availability.

As stated above, CryptDB utilizes a proxy server and some other components to the typical structure of database backed applications, which usually consists of a DBMS server and a separate application server. And mainly deals with two types of privacy threats:
1. DBMS software compromises, Root access to DBMS machines, Access to the RAM of physical machines.
2. The application server, proxy, and DBMS server infrastructures may be compromised arbitrarily.
And there are three methods that CryptDB uses to solve the problems:
1. (SQL-aware encryption) This approach is mainly based on the fact that SQL queries have a well known structure consisting of operators such as order comparisons, equality check and aggregates like sum and table joins. CryptDB then uses cryptographic methods for joins to transform the queries to a form that can enable the DBMS to run them on encrypted data.
2. (adjustable query-based encryption) It attacks the problem seen in the first techniques where certain cryptographic schemes leak more data than required.
3. (confidentiality for the content of the data) It chains the cryptographic keys to user passwords to enable decryption for users with access privileges.
And in total there are six choices of encryption: Random (RND), Deterministic (DET)Order-preserving encryption (OPE),Homomorphic encryption (HOM), Join (JOIN and OPE-JOIN), and Word search (SEARCH).

And for this paper, I think there are majorly two limitations in the design of CryptDB. Firstly, the only information encrypted in the database are the values of each cell, it does not hide the overall table structure, the number of rows, the types of columns, or the approximate size of data in bytes. Another more important issue is that, it only supports simple column wise rational queries, aggregate, and does not support more complex queries using both computation and comparison on the same column. For example, select S.name from S where S.index*2+3 > 555. And in real world use case, I believe those computations should be very common used and have large impact on the usefulness of a database.







Review 17

CryptDB is intermediate system that provide confidentiality for applications on DBMS. It adds an extra layer between application and DBMS server, which is called proxy. The proxy layer transform the client query into encrypted data query of the same semantic and sends it to the DBMS server. DBMS only queries on the encrypted data and sends the result back. This intermediate layer allows the DBMS operate only the encrypted data leaking minimum information at the DBMS server level. CryptDB dynamically chooses different encryption method for different query operations. For the encryption method, for efficiency concern, it uses onion encryption, which is a multi-layered encryption method. When certain operations are needed on the data(like comparison), the encrypted data is decrypted to certain level(but still encrypted) to allow more efficient operations.

Advantages:
CryptDB minimizes modification on the DBMS server while providing security feature to it. CryptDB adds an extra layer above the DBMS server and on the DBMS server, only thing needs to be done is to set up several UDFs for onion encryptions.

Disadvantages:
There might be some performance spikes when workload frequently changes. CryptDB uses onion encryption of table in the underlying server and based on the query operation, it chooses the efficient encryption type. However, the decryption itself is quite expensive (basic granularity is a column). If the workload changes often, changes between different encryption type might generate lots of overhead. In addition, if HOM encryption is used in this case, the operation to the data itself becomes expensive.


Review 18

This paper addresses the issue of confidentiality when storing user data in an untrusted database. The primary use case described is when a public cloud is used to store data and the application wants to prevent the confidentiality of the data from being compromised when the database is. The authors describe how CryptDB protects against stronger threats in a separate paper. The approach taken by the authors is to use multiple forms of encryption to provide varying degrees of confidentiality and SQL operation support. The types of encryption include random, homomorphic, deterministic, and ordered. Random does not allow for any operations to be performed on the data, homomorphic allows for simple algebraic operations to be executed, deterministic allows for equality comparisons to be made, and ordered retains the ordering of the original data. To provide flexibility in changing the level of encryption, data is encrypted in multiple onions where layers can be "peeled off" as needed to run whatever operations are necessary. A trusted proxy is used to encrypt and decrypt the data and rewrite SQL queries along with some user-defined functions that allow CryptDB to perform more functionality on the database. Using TPC-C, the authors saw 26% performance overhead on average.

The main insight in this paper is in identifying that multiple forms and layers of encryption can be used to provide some degree of confidentiality while still performing all data operations on the database (as opposed to moving them back to the client or proxy). The authors insight in choice of encryption algorithms is also worth mentioning as they have clearly thought through their choice of algorithms for this work. For instance, they use CMC encryption as opposed to ECB which would be the immediate choice made by someone who just took a security class (though it provides very weak confidentiality). Likewise to achieve other properties the authors resort to encryption algorithms that are not popularly used as their functionality is uncommon.

I found that the authors choice of encryption algorithms demonstrated the effort they put into this project. The paper also seems novel in that it is able to provide full (or nearly full) SQL functionality over encrypted data. However, the paper had some important weaknesses:
* CryptDB does not provide strong confidentiality for all forms of data. It is best for data where non-sensitive columns are queried and sensitive data remains encrypted with random ciphers.
* CryptDB encrypts all columns independently of each other. For some columns, few values may be used (e.g. a Male/Female column) which leaks information to an adversary.
* The authors do not spend much space discussing the latency overhead of CryptDB. For systems that handle user requests, latency is often the most important factor.


Review 19

This paper introduces CryptDB, a database that can protect users’ information by encrypting both queries and the values stored in the database. In recent years, information theft has been a big problem. Millions of medical records have been stolen as a result of data breaches. There is also another threat: an adversary that is listening to queries across the network can put together parts of the database based on the queries and responses. Both of these threats are solved by CryptDB, which executes SQL queries over encrypted data.

In order to ensure these properties, CryptDB has the following properties:

1. Any sensitive data on the database is not shown as plaintext at the DBMS server.
2. One cannot know anything about the sensitive data content other than its btyes.
3. Any equality checks will be done correctly, but we will not reveal what the actual values are.
4. If there are any order checks, the proxy reveals the order of the elements, but not the actual values of the elements.

Furthermore, to process a query, we can use the following steps:

1. The proxy receives the query, rewrites the query, and encrypts all of the constants with the master key.
2. It then checks if the server should be given keys to adjust encryption layers and sends the keys if needed.
3. The encrypted query is then sent to the server and executed.
4. The encrypted response is received by the proxy, decrypted and sent back to the user.

This paper has been very influential on the database community by providing a way to securely run queries on an encrypted database. It also manages to run all of the queries with just a 20% increase in runtime. However, I still have some concerns about the paper:

1. What if the adversary manages to grab the query before it reaches the CryptDB proxy? Is there any way to do end to end encryption?
2. The adversary can still find out the length of certain values and the schema of the tables. Is there any way to encrypt these parameters as well?



Review 20

This paper discusses CryptDB, a cloud-based database that stores all information in an encrypted format. As more and more companies move their databases to the cloud, a great deal of sensitive personal information is stored on online servers. Cyberattacks and information leaks are prevalent, so users want guarantees that their data will be safe if they host it at on a third-party system. CryptDB offers this security by allowing SQL queries to be executed on encrypted data and return encrypted results that can be decrypted on a trusted client machine.

CryptDB encrypts columns with different levels of encryption based on which types of queries need to be run against that column. Randomized encryption (RND) provides the strongest encryption, but no operations can be executed on data encrypted in this manner. Deterministc encryption (DET) allows for equality comparisons, order-preserving encryption (OPE) allows for range-based queries and ordering. Homomorphic encryption is as secure as RND encryption and allows addition of encrypted values, but computation is expensive. One of the key features of CryptDB is adjustable encryption levels. When data is loaded, it is encrypted multiple times, with increasingly stronger levels of encryption in what the authors call an “onion of encryption”. Then, when a query is run that requires a lower level of encryption, a UDF is executed to decrease the encryption level on the column. This reduced level of encryption is persistent in order to prevent heavy decryption cost every time a similar query needs to be run against that column.

The authors ran several experiments to determine the performance and security of CryptDB. Results showed that most sensitive information remained encrypted with either DET or RND at steady state, since it was primarily loaded, then read as part of queries involving selection on a non-sensitive column. When testing performance, the authors determined that CryptDB exhibited 26% lower throughput on the TPC-C benchmark, and 14.5% lower throughput on the phpB B application. They believed that this performance hit was a modest price to pay for the security benefits offered by CryptDB.

My primary concern with this paper is their statement near the end of the paper that CryptDB does not ensure correct query results. Obviously the security benefits of CryptDB are significant, but correctness of results is also an incredibly important issue which they present as no more than an afterthought. I would have liked a more thorough discussion of the level of inaccuracy expected/tolerated for an application using CryptDB.



Review 21

This paper presents CryptDB, which is the first practical system that can execute a wide range of SQL queries on encrypted data. Theft of private data information is a significant problem for many applications nowadays. One approach to deal with this problem is to encrypt the data, and let user decrypt and process the data. However, the user cannot perform as many computations as the server. Therefore, this paper introduces CryptDB, in which SQL operations can perform on encrypted data.

First, the paper talks about two threats that can happen in DBMS, including DBMS server compromise and arbitrary threat. Then, the paper introduces CryptDB, in which queries can perform on encrypted data. It addresses many useful operators, including JOIN, ORDER, and SEARCH.



Review 22

This paper is an introduction to CryptDB, a DB setup focused on data privacy and security. CryptDB works on an entirely encrypted dataset that is encrypted with an onion style similar to the previous paper we read. It is capable of processing queries over the encrypted data because of the different styles of encryption used. Some preserve ordering, some only preserve equality, and some preserve both but are slower. CryptDB tries to offer a sufficient amount of data protection while still not hindering performance too much.

CryptDB works by sending every query through a proxy that encrypts each constant in the query with a key that is tied to the user’s password. This ensures that without control of the proxy an attacker will not know what the unencrypted data is as it is never worked with. However, with access to the proxy an attacker can gain access to the queries that are coming in and see what values encrypt to and thus have sensitive data. Another problem with this password setup is it would be impossible to share data if the values were encrypted by one user’s password. Because of this for shared data they have created a solution that chains together passwords of the people sharing the data so that it can be used by that.

If the proxy (and whole system) is attacked CryptDB can only guarantee confidentiality of users who are not logged in, as they will not be running any queries and thus their data will stay encrypted. Users who are logged in though are not guaranteed any securities in the event that the whole system is attacked, which is rather unlikely.

The paper also touches on all the types of encryption and what queries they can run with their level of encryption and their upsides and downsides. I will not cover this though as it is pretty well covered in section 3.1 of the paper. Lastly, the performance of CryptDB is pretty good as it only performs slightly worse than normal MySQL (which it is built on top of).

I think this was a really good paper and I would be a strong proponent of using CryptDB. I am rather security conscious and I think for most smaller companies dealing with modestly small data the slowdown won’t particularly be an issue and the added safety guarantees are a huge upside. I really enjoyed this paper and it was really well written I think! It was a new format, different from the rest of the papers and it was a pleasant change of pace! Overall, a solid paper.



Review 23

As the title implies, the goal of this paper is to discuss privacy and security in database systems, pitfalls of current approaches to improve security. DB breaches are far more common than we think; in 2012 6.5 million hashed passwords were passively stolen from LinkedIn’s databases. One approach may be to encrypt all the data, decrypt on a trusted server to perform computations (which are difficult on encrypted data), and return encrypted results. However the throughput incurred in this system is quite costly, so other methods, such as fully homomorphic encryption (where computations can be done in encrypted space) have been an active area of research, but are still slow for the most part. CryptDB is a database system that still protects user data with modest overhead (26% overhead on TPC-C).

The first threat model is through the eyes of a passive attacker, one that has access to the encrypted database, but does not intend to change queries or results. The CryptDB setup to protect against this is through a proxy which transforms plain, unencrypted queries to perform computations on the encrypted database, which returns encrypted results, at which point the proxy returns the decrypted results. All the proxy needs to know is the schema and the master key for query transformations. SQL-aware query encryptions allow ordering, equality, aggregation, and joins on the encrypted data. However, like the l-diversity paper pointed out, I feel like this can still be subject to an attack to estimate the distribution for certain sensitive encrypted attributes. The second transformation is through “adjustable query-based encryption.” Each item value in a column is encrypted with decreasing levels of security (starting with most secure encryption scheme RND->DET->OPE->HOM, which are all fairly self-explanatory), where the proxy transforms queries based on classes of computation for different layers in the encryption onion. For example, an attacker cannot learn the relations between columns without knowing the exact token used for encryption and computation. The columns to be joined should not be known a priori to the database. The proxy gives keys to the DB server via a UDF, remembering the onion layer for each specific column and updating the UDF keys for encryption if necessary.

Given their scheme, the encryptions exposed for each column are most secure and only vary based on query semantics. Data relations are only revealed for a needed query type, and even so, it is at column granularity (e.g. equality predicates follow from the DET scheme, aggregation follows from HOM, select follows from RND), and each doesn’t reveal plaintext. The most sensitive columns stay above some security threshold, and are never revealed beneath the RND layer (most secure).

The selling point of the CryptDB system is its portability, and its ability to be implemented on other systems; moving from Postgres to MySQL took only 86 lines, with no changes to the user-facing application. Since CryptDB exists outside of the original database (i.e. in the proxy and the set of UDF’s on the encrypted DB). The evaluation phase of the paper, I think, addressed some good points in terms of: what queries/applications are supported? What is the actual resultant layer of confidentiality? And what is the overhead incurred? They do not support complex operators that require combining encryption schemes (like compare and add), but they offer solutions like splitting queries, but I think this can also be resolved maybe using precomputed columns if there is information known beforehand, or by using FHE/other encryption schemes. However, in the table they gave comparing different applications and the number of columns supported, even in the MIT SQL database, 1094 out of ~130,000 didn’t seem too bad. In addition, the latency throughput loss they suffer is about 26%, which I can see as being reasonable, unless the application needs (a) security and (b) very high throughput.

I can see a couple of key problems with the CryptDB system; if multiple encrypted copies of fields are kept on a server somewhere, then there are probably HUGE files being written to disk in order to store everything, especially for larger databases. In addition, if a user simply adds a couple simple complexities to a query, it automatically weakens the encryptions over the columns it targets. Lastly, adding more layers to a system is usually a no-no in the field of security. Just by adding the proxy, there is a new target in the system! And it is so much worse; if the proxy is exploited, then the whole system is foiled. Perhaps the next level of security is through hardware-assisted encryption schemes, which would make it extremely difficult for hackers to control without physical access to the actual machines.


Review 24

This paper talks about CryptDB, a practical system that explores an intermediate design point to provide confidentiality for applications that use DBMS. The motivation behind the paper is because to prevent information theft, data needs to be protected – which is usually done by encrypting data – but data also needs to be available for computation. In short, the DBMS must be able to query encypted data. Using CryptDB, the DBMS is able to do that with minimum overhead.

The paper starts with explanation of threat model. There are two threats: DBMS server compromise (attacker has full read access to the data in DBMS) and arbitrary threats (attacker has compromised the server, the proxy, and the DBMS). The architecture of CryptDB is built on top of existing DBMS. Next, it explains how CrypdtDB executes SQL queries over encrypted data. CryptDB uses SQL aware encryption. There are six types of encryption in CryptDB: RND (maximum security), DET (can be used to perform equality check), OPE (can be used to determine order relation), HOM (can be used to perform computation), JOIN/OPE-JOIN (for equality join), and SEARCH (for searching). For one data value, there will be multi-layer encryption. The outmost side is the strongest encryption. When a query wants to do operation, the layer will be decrypted until it reaches the layer which allow the data operation. Therefore, different type of operation results in different level of layer decryption. The paper continues with the practical example of query execution of encrypted data that is supported by onion layer model (most relational queries and aggregates) and computing join, as well as discusses query limitation for this onion layer (i.e.: it does not support order comparison with summation). Next, the paper presents experimental evaluations using five application and one large trace. Functional evaluation shows that CryptDB can process most of the queries (when tried on the trace data, it supports roughly 99% of the column queries). Security evaluation shows that onion layer model helps improve data confidentiality, and performance evaluations shows that the tradeoff in throughput rate is still acceptable. Last, several related works mentioned are search and queries over encrypted data, untrusted servers, disk encryption, software security, and query integrity.

The main contribution of this paper is it presents us with a (more) secure system which enables user to do query and computation on encrypted data, which supports most of SQL query operation but with decent tradeoff in performance. The concept of onion layer makes it impossible for the system to decrypt “as needed”, which means that system does not need to decrypt everything (thus revealing the original value of the data) when it is not really necessary to do so.

One question that arises after reading this paper is that it is back to human expert to define which columns are sensitive and which one are not. It may be easy to point 1-2 columns out of 10 columns, but would not it be painful if there hundreds of column (in the case of sql.mit.edu trace, there are more than 500 columns so the writers just decided to encrypt them all and use it for performance benchmark). There is also this question about quasi-identifier, as in columns that when used alone they do not seem sensitive but when combined with other columns they have potential to reveal sensitive data. Is it possible for CryptDB to “learn” to recognize such potentials?--



Review 25

The purpose of this paper is to present CryptDB, which is the first system that allows for the execution of a wide range of SQL queries on encrypted data. In other words, data does not have to be decrypted in CryptDB in order to determine the results of user queries, which is great. They do this with only a roughly 25% speedup, which is much better than the 10^9 speedup they cite of other methods.

The technical contributions of this paper are numerous. In this paper, the authors present their adjustable query-based encryption technique that they describe like an onion. The level (and type) of encryption can be changed on a subset of the data based on the type of query the user is attempting to execute on the data. Each data item is stored in an Onion of encryption schemes and the layers of the onion are peeled back (to lower-security encryption schemes) as needed. They also present a system model that includes a Proxy server between the Application and the DBMS that does all of the necessary translations of SQL queries as well as manages the encryption and decryption of data. Additionally, they present their new scheme for joining encrypted columns. Join columns must be encrypted with the same keys, however if the workload is not known in advance, the Proxy server does not know which columns need to be encrypted with the same key. CryptDB adds an adjustable join to the cryptographic primitives which allows the DBMS server to adjust the encryption key of columns at runtime if they need to be joined.

I think a major strength of this paper is its ease of integration with existing SQL systems. The use of a proxy server increases security in certain compromise situations and adds a level of abstraction that allows an almost seamless integration with existing DBMSs and their respective workloads. I think another strength is their performance improvement over some similar existing systems. This improvement is well-documented in their empirical results section.

As far as weaknesses go, I think there are some unfortunate assumptions made in this paper. With regards to types of attacks they prepare for, the article makes some broad assuming statements that are not justified at all. Perhaps these assumptions would be more clear to someone with a background in security, but to me they are completed unsubstantiated.



Review 26

This paper proposed CryptDB, a database that can query on encrypted data without modifying the existing DBMS. This paper first introduces why encryption for database application is important: attacks for the online applications may leads to leakage of the data, and DBA from the data host may snoop on the private data. In order to solve this problems, the paper states that data should be encrypted on its storage layer and also when communicate over the network. CryptDB, as a solution for the previous defined problem, has perfectly accomplished the stated features yet does not need any modification of the existing DBMS. CryptDB utilized the property that a SQL plan is just a graph construct from a limited set of operators, so for each sql operator, it defines a corresponding encryption version operator using different encryption techniques, for example OPE for order by and DET for equalTo. Moreover, in order to provide the best performance while still maintaining its encryption property, CryptDB utilize a technique called Onion Encryption layer, that at beginning all data are encrypted with the highest encryption methods and would be removed when a request tries to run the operator on a lower encryption level. This feature is added for the reason that the workload is unknown before the runtime.

Strengths:
1. This paper introduces CryptDB, a database that can run queries on encrypted data without modifying the existing DBMS. This provide a security protection from the database layer, and protect the data in an efficient way.
2. This paper introduces the Onion Encryption Layer. This runtime adjustable encryption technique helps the system to tradeoff between computation power towards the encryption level.
Weakness:
1. CryptDB can only downgrade the security level of the data based on its onion encryption technique. However, it would be nice if application can decide the encryption level and also decide on the tradeoff between Security and latency.
2. CryptDB does a complete experiment toward different applications. However, it is noticed that the paper does not have any experiment result on the data size. It would be more interesting to see the performance of CryptDB on different data size.



Review 27

This paper introduces CryptDB, a frame work for processing queries on encrypted database. As application developers are used to put data on cloud database, server
compromises becomes a severe threat to data confidentiality. The data encryption scheme has been widely applied in networked file system. However, many important applications, including database-backed Web services that process SQL queries,
as well as analytic applications that compute results over large quantities of data, require servers to not just store data, but also perform computations on the data.
CryptDB is a framework that enables databases servers to perform all computation on encrypted data.CryptDB consists of a trusted proxy and an untrusted database server. All data stored on database is encrypted. The direct operations on data are performed by User-Defined Functions. Application sends plain queries to the proxy. The proxy then translates them to SQL queries with UDF. The database server process queries over encrypted data and sends back encrypted result to proxy server. At the end proxy server decrypts the result and send it back to application. To achieve the performance goal, CryptDB carefully select the encryption scheme for a column by looking at the query running on it. Every column is encrypted with multiple levels of encryption scheme, just like an onion. The proxy will instruct the database server to strip off the encryption onion until reaching the highest level of confidentiality while satisfying the query’s computation need. By leverage different encryption schemes, CryptDB exposes as little information as possible.

The advantage of CryptDB is that the whole framework doesn’t require any change to server-side database software. The only change is adding a trusted proxy server between application and database server, as well as a few User-Defined functions. This paper shows that the design is compatible with MySQL and Postgres.

One weakness of this paper is that adding a trusted proxy server doesn’t ultimately solve the problem. An attacker can still invade the proxy server, get the encryption keys, and have access to all the data on servers. This approach just transit the attraction of attackers from the database server to proxy server. CryptDB will still be compromised if any encryption credential on the proxy server leaks.