Deswegen haben wir zuerst unsere gewünschten Anforderungen an das Verfahren bezüglich Sicherheit, Funktionalität und Performance festgelegt:  

• Sicherheit:  So wenig wie möglich über die Struktur der Daten und Häufigkeit der Schlüsselwörter preisgeben und bekannten Angriffen auf Searchable Encryption widerstehen.
• Funktionalität :
  • Einfache Schlüsselwortsuche durch einen Benutzer
  • Sichere dynamische Updates, dass heisst Zufügen und Löschen von Dokumenten effizient unterstützen
  • Soll auch Ressourcen beschränkte Clients unterstützen (Smart Phones ebenso)
• Performance:
  •  Sublineare Suchzeit bezüglich der Anzahl der Dokumente
  • Bestmögliches Verhältnis zwischen Sicherheit und Effizienz bezüglich Rechenaufwand und Speichergröße sowohl am Client wie auch am Server

Unsere Evaluierung der Verfahren hat ergeben, dass keines den Anforderungen vollständig gerecht wird. Wir hätten gerne ein Verfahren gefunden, bei dem kein  Zustand am Client gespeichert werden muss. Aufgrund neuer Angriffsvarianten wie "File Injection Attacks", die Forward Security Verfahren  erfordern, welche   nur mit Zustandsspeicherung am Client auskommen.  Bei Foward Secure Verfahren ist es für einen Angreifer aus der Sicht des Servers nicht möglich, neue  Einträge auf die Übereinstimmung mit einem Schlüsselwort zu evaluieren. Obwohl  für dieses Schlüsselwort vorher bereits eine Suchanfrage gestellt wurde.   Praktisch haben wir die Verfahren auch nach möglichst geringer Komplexität  und dem Vorliegen von Open Source  Vergleichsimplementierungen ausgesucht.Deshalb fiel unsere  erste Wahl auf ein Verfahren Dyn2Lev von Cash et al, das bereits in einer modifizierten Version in der Clusion Library Arbeitsspeicher (RAM)-basierendimplementiert ist. Diese Version haben wir auch so in das Framework integriert. Jetzt geht es daran, das Verfahren auf unser Framework hin zu optimieren und die Indizes von mehreren Usern über ein effizientes Key-Value Store  auf der Festplatte zu speichern. Für das Key/Value Store verwenden wir RocksDB.