The protocol Π3(E)can be extended in various ways that may be of interest and that we will
discuss here. The first “extension” is simply the removal of the file encryption step described in Section 4.2.3, which is suitable for the standard two-party model where theserver’s input need not be kept secret from theserverhimself. This simplification eliminates thedk,βkandbkvalues from the protocol, implicitly settingβk= 1.
A more interesting variant of the protocol addresses the concern that the protocol as stated in Fig. 4.1 discloses the decryption keydkand the valueshβkik∈[ℓ]to theclient, either of which can be
used to decrypt the file from its ciphertexthsk, bkik∈[ℓ]. While this file ciphertext is not disclosed to
theclientduring the protocol, it seems unnecessarily permissive to disclose its decryption key to ev- eryclientthat performs a DFA evaluation on the file: if the file ciphertext were ever unintentionally disclosed, then any suchclientcould decrypt the file if it retained the key. In the rest of this section we discuss an extension to the protocol in Fig. 4.1 to avoid disclosingdk and the valueshβkik∈[ℓ]to
theclient.
In order to avoid disclosing dk to theclient, one alternative is for the data owner to provide shares ofdkto both theclientand theserver, so as to enable a two-party decryption of eachbk. Then, rather than sending onlybkto theclientin messagem304, theservercan also send its contribution to the decryption ofbk, enabling theclientto complete the decryption of bk without learningdk itself.
Still, however, this alternative would discloseβkto theclient, which would enable it to deter- mineσk if sk were ever disclosed. To avoid disclosing βk, one strategy is for the server to first blindβkwith another random valuetk, i.e., to execute the protocol withβktkin place of justβk. Of course, this factortkwould also then need to be reflected ink-th file character used in the protocol, i.e., so theserverwould usestk
k =H1(σk||k)xβktk in place ofskin the protocol. Because theserver does not have access to βk but rather has access only to its ciphertext bk, it is necessary that the encryption scheme used to construct bkenable the computation of a ciphertextˆbk frombk and tk such that Decdk(ˆbk) = βktkmodN′ for some valueN′ such thatp | N′. In this case, selecting tk ←$ ZN′ suffices to ensure thatβktk modN′ is distributed independently ofβkand so hidesβk from theclientwhen it learnsβktkmodN′.
An encryption scheme meeting our requirements (supporting two-party decryption and homo- morphism on ciphertexts) is ElGamal encryption [30] in a subgroup ofZ∗
N′. However, note that settingN′ = pis inefficient: the security parameterκand so the size ofprequired for security is an order of magnitude less for BLS signing than it would be for ElGamal encryption in a subgroup ofZ∗
p[52], and so settingN′ =pwould add considerable expense to the protocol. As such, a more efficient construction would be to choose N′ = pp′ for another primep′. ElGamal encryption is believed to be secure with a composite modulus even if its factorization is known [14].
CHAPTER 5
Toward Practical Encrypted Email That Supports
Private, Regular-Expression Searches
In this chapter, we prototype a system to perform private regular expression searches on en- crypted emails and evaluate its performance. Toward this goal, we develop new protocols to enable private regular expression searches on encrypted data stored at aserver. The novelty of the protocol lies in allowing a user to securely delegate an encrypted regular-expression search query to aproxy, which interacts with theserverwhere user’s data is stored encrypted to produce the search result for the user. The privacy of the query and the data are both provably protected against an arbitrarily maliciousserverand a partially trustedproxyunder rigorous security definitions. We then develop a working implementation of this protocol together with several optimizations to make it perform well and then evaluate the performance of this implementation on a real-world email data set. We describe our initial protocol design in Section 5.1 and detail a series of optimizations we employed in Section 5.2, and finally present the implementation and its performance evaluation in Section 5.4.