Bestie: Very Practical Searchable Encryption with Forward and Backward Security

Abstract

Dynamic searchable symmetric-key encryption (DSSE) is a promising crypto-tool that enables secure keyword searching over dynamically added or deleted ciphertexts. Currently, many works on DSSE devote their efforts to obtaining forward and backward security and practical performance. However, it is still challenging to design a single DSSE scheme that simultaneously achieves this security, high performance, and real deletion. Note that real deletion is a critical feature to guarantee the right of the user to be forgotten stipulated by GDPR. Due to this fact, we propose a new forward-and-backward secure DSSE scheme named Bestie. To achieve high search performance, Bestie takes the traditional hash and pseudorandom functions and symmetric-key encryption as building blocks and supports parallel keyword search. Bestie also achieves non-interactive real deletion for avoiding the client to do a clean-up process. This feature not only guarantees the above GDPR rule but also makes Bestie more suitable for managing large-scale data. Bestie also saves the client’s computation and communication costs. Finally, we experimentally compare Bestie with five previous well-known works and show that Bestie is much better in most respects. For example, Bestie requires approximately 3.66 microseconds to find a matching ciphertext. In contrast, Bestie has search performance at least 2 times faster than both $\texttt {Mitra}^*$ (CCS’18) and $\texttt {Diana}_{del}$ (CCS’17), 1,032$\times$ faster than Fides (CCS’17), and 38,332$\times$ faster than Janus++ (CCS’18), respectively. Compared with Mitra (CCS’18), Bestie saves at least 80% client time cost during a search.

A Proof of Theorem 1

Proof

To prove the forward and Type-III-backward security of the proposed Bestie, we construct a $\mathcal {S}$ simulator, which takes as inputs leakage functions $\mathcal {L}^{Stp}(\lambda )=\lambda$, $\mathcal {L}^{Updt}(op,w,id)=\emptyset$, and $\mathcal {L}^{Srch}(w)=\{\text {sp}(w), \text {TimeDB}(w), \text {DelHist}(w)\}$ to simulate protocols Bestie.Setup, Bestie.Update, and Bestie.Search, respectively. We will demonstrate that the simulated Bestie is indistinguishable from the real Bestie under the adaptive attacks. Algorithm 2 describes the simulator $\mathcal {S}$. Specifically, the simulator $\mathcal {S}$ consists of the following three phases.

Protocol $\mathcal {S}.\textsf {Setup}$. This protocol simulates protocol Bestie.Setup. In this protocol, simulator $\mathcal {S}$ takes leakage function $\mathcal {L}^{Stp}(\lambda )=\lambda$ as input and initializes five empty maps $\mathbf{CDB}$, $\mathbf{GRP}$, $\mathbf{CipherList}$, $\mathbf{GIndlist}$, and $\mathbf{Xlist}$, where $(\mathbf{CDB} , \mathbf{GRP} )$ will be sent to the server and the remaining maps are kept as internal states of simulator $\mathcal {S}$. The map $\mathbf{CipherList}$ records the ciphertexts generated by simulator $\mathcal {S}$. The map $\mathbf{GIndList}$ records the group indexes for the following Search queries. Map $\mathbf{XList}$ records the simulated values of hash function G. Clearly, the simulated protocol is indistinguishable from the real one in the view of adversary $\mathcal {A}$.

Protocol $\mathcal {S}.\textsf {Update}$. This protocol simulates protocol Bestie.Update. In this protocol, simulator $\mathcal {S}$ takes nothing as input. It randomly chooses a random triplet (L, D, C) as the generated ciphertext and uploads it to the server. In the real world, $\mathbf{H}$ is a collision-free hash function, and $\xi$ is a semantically secure symmetric encryption scheme. Hence, the random triplet is indistinguishable from a real ciphertext if adversary $\mathcal {A}$ does not know the corresponding search trapdoor. The following content will prove that the random triplet is still indistinguishable from a real ciphertext, even in the opposite case.

Protocol $\mathcal {S}.\textsf {Search}$. This protocol simulates protocol Bestie.Search. In this protocol, simulator $\mathcal {S}$ takes the leaked information $\text {sp}(w)$, $\text {TimeDB}(w)$, and $\text {DelHist}(w)$ as inputs. Simulator $\mathcal {S}$ first checks whether there exists any historical $\textsf {Update}$ query about keyword w. If not, simulator $\mathcal {S}$ aborts, as the real protocol does (refer to Steps 2 to 4). Otherwise, simulator $\mathcal {S}$ sets or retrieves the group index $I^{grp}_{u_s}$ of keyword w (refer to Steps 5 and 6). In the following content, simulator $\mathcal {S}$ must program oracle H such that the randomly generated search trapdoor is still valid in the view of adversary $\mathcal {A}$ (refer to Steps 8 and 15).

In this part, simulator $\mathcal {S}$ mainly achieves two aims: (1) simulate hash values of function G for all Update queries of keyword w as well as guarantee that the Update queries of the same keyword-and-file-identifier entry have the same hash value (refer to Steps 10 to 12) and (2) program oracle H such that all simulated ciphertexts of keyword w can be correctly found by the server with the randomly generated search trapdoor (refer to Steps 13 and 14). Finally, simulator $\mathcal {S}$ sends the randomly generated search trapdoor to the server. The transcripts generated by the simulated $\textsf {Search}$ protocol are indistinguishable from those of the real protocol since all operations are consistent with the real protocol in the view of adversary $\mathcal {A}$.

To summarize, there exists a $\mathcal {S}$ simulator to simulate Bestie with the given leakage functions, and the simulation is indistinguishable from the real Bestie. Thus, Theorem 1 is true.    $\Box$