Derzeitiger Stand ist: wir haben zwei Varianten des DynRH2Lev Verfahren aus der Clusion Library in das Searchitect Framework integriert. Eines memory basierend und das Zweitere persistiert den verschlüsselten Index in ein Key/Value Store (RocksDB).  Zur Erinnerung Forward Privacy oder Secrecy heißt, dass der Server keine Rückschlüsse auf  Schlüsselwörter durch neue Indexupdates ziehen kann, obwohl diese bereits zuvor gesucht wurden. Das DynRH2Lev Verfahren erreicht Forward Privacy indem es für jeden Dokumentbezeichner ein SearchToken in der Suchabfrage schickt. Zum Vergleich mit einem anderen Forward Private Verfahren haben wir das Sophos Verfahren gewählt, dieses ermöglicht Forward Secure Abfragen basierend auf asymmetrischen Trapdoor Permutationen. Alle drei Implementierungen wurden integriert und anschließend eine Test Simulation mit steigender Input Größe geschrieben. Zum Einen wird mit einem synthetisch erstellten Index getestet und  zum Anderen mit realistischen Dateien, dafür haben wir  öffentlich zugängliche Email-Sammlungen aus dem ENRON Datenset anonymsiert  verwendet. Die ersten statischen Tests brachten schlechte Ergebnisse, die Implementierungen haben schlecht  skaliert und bereits bei ein paar MB großen Dateiverzeichnissen Fehler geworfen. Schuld daran hatte eine falsche Parametrisierung der Anzahl der verschlüsselten Dokumentbezeichner, die in dem DynRH2Lev Schema  in einem Dictionary und  Array Block  enthalten sind. Durch empirische Tests haben wir eine mögliche Parametrisierung mit steigender Eingabegröße ermittelt und wieder getestet. Weiters wurde der Source Code der originalen DynRH2Lev Variante aus der Clusion Library modifiziert und optimiert, so entstand die DynRH2LevRocks  Variante  mit weitaus besseren Testergebnissen.

Vergleich zwischen der modifizierten DynRH2LevRocks Variante mit Sophos:

• Laufzeit für Updates: DynRH2Lev braucht 100 fach weniger Zeit für Updates
• Speicherverbrauch des verschlüsseleten Index: der Speicherbedarf von DynRH2Lev ist 10% größer, dafür aber im Gegensatz  zu Sophos doppelt verschlüsselt damit erfährt der Server keinen Klartext Dokumentenbezeichner
• Laufzeit der Suche: Die Suchzeit der DynRH2LevRocks Implementierung steigt weniger mit der Anzahl von Dokumenten, welche das Suchwort beinhalten, als die Sophos Variante.

  

  Der steigende Suchaufwand bei Sophos liegt vor allem an der sequentiellen Berechnung der asymmetrischen Trapdoorpermutation für jeden Treffer.

Als nächstes werden wir die Suchfunktion in eine Anwendung integrieren, deswegen sind wir derzeit noch mit der Auswahl einer passenden Anwendung beschäftigt. Außerdem haben wir eine öffentliche Umfrage zur Verwendung von Suchfunktionen in Anwendungen gestartet.  Diese besteht aus 9 kurzen Multiple Choice Fragen, wir freuen uns über Ihre Teilnahme unter diesem Link. https://surveys.questionpro.eu/a/TakeSurvey?tt=QMG%2BpfKEuBf4PGM79HY7mU… Vielen Dank.