# Searchable Data Vault: Encrypted Queries in Secure Distributed Cloud Storage
## 4 A Multi-Server SSE Scheme  
Now, we describe our scheme implemented in the SDV API. Figure 3 provides detailed steps of the scheme. The scheme consists of three functions. There is a Setup algorithm, a Search protocol and an Update algorithm. In brief, a user submits a document and the Setup algorithm processes it, resulting in encrypted blocks \(C=\{\mathbf{c}_{1},\ldots\mathbf{c}_{s}\}\), an index table \(I\), and secret keys \(K\) that must be stored securely by the users. The index table \(I\) stores the links between the filename, the blocks and the servers that store these blocks. In order to search for a document, a user submits a filename of a document \(D_{i}\) to the Search protocol, which then generates a filename token \(tok_{i}\). The protocol checks the index table \(I\) to find whether the \(tok_{i}\) matches any of the entries. If yes, then the entry is retrieved. If not then it returns false. The entry contains the links from which servers all the encrypted blocks of the searched document can be retrieved. In our implementation, this entry is used by the SDV controller to retrieve the encrypted blocks, decrypt and combine them to form the document.  
The Update algorithm provides for adding and removing of documents. Adding a document can be provided by using the processes in the Setup algorithm to encrypt the blocks and creating the index entry for the document. In a similar way, removing a document involves using the processes in the Search protocol to retrieve the index entry. However, instead of using the entry to retrieve the encrypted blocks, a delete command is issued to remove these blocks from the servers. We note that the mechanisms to submit and retrieve encrypted blocks are not discussed in the scheme. In our implementation we built a submit and a retrieve function in the SDV controller for this purpose.  
ExtensionThe Update algorithm may be extended to allow for adding or removing a storage server \(S_{a}\). A basic approach for server addition is to add the server identifier \(id(S_{a})\) into the list of existing servers \(S\). The existing storage arrangements and index table \(I\) will not be modified. The new server \(S_{a}\) is involved for storing encrypted blocks only when a new document is submitted. It is a bit more complicated for removing a server, since it involves all the encrypted blocks stored in the server. A simplest approach is to retrieve all blocks from the server, and runs Setup to redistribute these blocks. Nevertheless, the index table \(I\) must be updated by removing all the entries to the server beforehand. This was also discussed in [3].  
Expressive SearchThe Setup algorithm generates index entries that can be queried based on filename, \(F_{k_{f}}(filename(D_{i}))\). These entries are passed to the SDV controller to create an index table \(I\), as was previously discussed in Figures 1 and 2. While a query based only on filename seems to be a limitation, there are two main benefits in our consideration of using such an approach. Firstly, users normally send and view their documents to and from a cloud storage in a folder mode, by browsing through the documents. This fits well with the query by filename approach. Secondly, and more importantly, by using such an index entry setting, it is thus possible to create a two-level query index. The base level index provides query on filename that pulls the documents from the cloud storage as was presented in our scheme. An upper level index can then be created to allow for any type of expressive search (e.g., range, substring, Boolean, conjunctive) based on keywords that return filenames.