0
$\begingroup$

I'm new to this field,Symmetric Searchable Encryption, and have read some papers in this field. Notice lots of these papers about SSE use identifiers when build encrypted index and return identifiers as the search results to users.

These schemes seems work like this: when users get the identifiers, then use them to download files from server or server just sends the files along with the identifiers in search phase.

What bothers me is , when get a search result like $ids = \{doc1.txt,doc2.txt,doc3.txt \}$, What's the next step? When user talks to server and say give me the file named $doc1.txt$ , the server can easily give the user some other file and just name it as $doc1.txt$ and return it to the user.

I know there is Verifiable Symmetric Searchable Encryption, but it seems the "verifiable" means the search result is verifiable ,i.e if the result is $ids = \{doc1.txt,doc2.txt,doc3.txt \}$ ,the server can not send $ids = \{doc1.txt,doc3.txt \}$ since the user can verify. But still the server can fool user by the rename trick.

How these kinds of problem solved?
Do I miss something and misunderstand something?

Reference
[1] Bost, Raphael. "∑ oφoς: Forward secure searchable encryption." Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. 2016.
[2] Demertzis, Ioannis, et al. "Dynamic searchable encryption with small client storage." Cryptology ePrint Archive (2019).
[3] Bost, Raphaël, Brice Minaud, and Olga Ohrimenko. "Forward and backward private searchable encryption from constrained cryptographic primitives." Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. 2017.
[4] Bost, Raphael, Pierre-Alain Fouque, and David Pointcheval. "Verifiable Dynamic Symmetric Searchable Encryption: Optimality and Forward Security." IACR Cryptol. ePrint Arch. 2016 (2016): 62.

$\endgroup$
2
  • $\begingroup$ Presumably, the user can decrypt the file and remembers what she searched for. It should be pretty obvious if the server returned a file that didn't contain the search terms. $\endgroup$ Oct 18 at 21:32
  • $\begingroup$ @AmanGrewal,thanks, that make sense. I am trying to find is there a technical way to prevent this situation. $\endgroup$
    – zbo
    Oct 19 at 2:35
0
$\begingroup$

If you're using an AEAD cipher, you can use the id as the additional data. When the client tries to decrypt the file, the decryption will fail if the server tries to swap files.

$\endgroup$
2
  • 1
    $\begingroup$ After reading the answer and this post security.stackexchange.com/questions/179273/… , i think it is solved. We can use the 'identifier' as the 'associate data' in AEAD and if the content of file is changed , It will fail to decrypt with the 'identifier' as AD. $\endgroup$
    – zbo
    Oct 20 at 4:55
  • $\begingroup$ Hence the rename trick won't work. $\endgroup$
    – zbo
    Oct 20 at 4:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.