Sunt nou în acest domeniu, Symmetric Searchable Encryption și am citit câteva lucrări în acest domeniu. Observați că multe dintre aceste lucrări despre SSE folosesc identificatori atunci când construiesc un index criptat și returnează identificatori ca rezultate ale căutării utilizatorilor.
Aceste scheme par să funcționeze astfel: atunci când utilizatorii obțin identificatorii, apoi le folosesc pentru a descărca fișiere de pe server sau serverul trimite doar fișierele împreună cu identificatorii în faza de căutare.
Ceea ce ma deranjeaza este , când obțineți un rezultat de căutare, cum ar fi $ids = \{doc1.txt,doc2.txt,doc3.txt \}$, Care este următorul pas? Când utilizatorul vorbește cu serverul și spune dă-mi fișierul numit $doc1.txt$ , serverul poate oferi cu ușurință utilizatorului un alt fișier și doar îl poate numi ca $doc1.txt$ și returnați-l utilizatorului.
Știu că există o criptare simetrică verificabilă, dar se pare că „verificabil” înseamnă că rezultatul căutării este verificabil, adică dacă rezultatul este $ids = \{doc1.txt,doc2.txt,doc3.txt \}$ ,serverul nu poate trimite $ids = \{doc1.txt,doc3.txt \}$ deoarece utilizatorul poate verifica. Dar totuși serverul poate păcăli utilizatorul prin trucul de redenumire.
Cum s-au rezolvat astfel de probleme?
Îmi lipsește ceva și înțeleg ceva greșit?
Referinţă
[1] Bost, Rafael. „â oÏoÏ: Redirecționați criptarea securizată care poate fi căutată.” Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security. 2016.
[2] Demertzis, Ioannis, et al. „Criptare dinamică care poate fi căutată cu spațiu de stocare mic pentru client.” Arhiva Cryptology ePrint (2019).
[3] Bost, Raphaël, Brice Minaud și Olga Ohrimenko. „Criptare privată cu căutare înainte și înapoi de la primitive criptografice constrânse.” Proceedings of the 2017 ACM SIGSAC Conference on Computer and Communications Security. 2017.
[4] Bost, Raphael, Pierre-Alain Fouque și David Pointcheval.„Criptare dinamică și simetrică verificabilă: optimitate și securitate directă.” IACR Cryptol. ePrint Arch. 2016 (2016): 62.
