fts encrypted
1.0.0
Hinweis: Token bezieht sich auf lexikalisches Token , nicht auf kryptografisches Token . Zum Beispiel kann ein Tokenizer "Lernende", "Lernen", "gelernt" in das Token "Lernen" werden.
Wenn Sie keine Verschlüsselung benötigen, ist Tantivy in jeder Hinsicht besser.
Eine grundlegende GUI -Demo mit Dioxus und dem Enron -E -Mail -Set finden Sie in meinem GitHub. In erster Linie ist zu zeigen, dass die Suchgeschwindigkeit für die Art der Datensätze, die auf clientseitigen Anwendungen gespeichert sind, angemessen sind.
Dies ist noch in Arbeit. Es werden keine Garantien für diese Bibliothek oder ihre Abhängigkeiten bei der Implementierung, konzeptionell oder auf andere Weise gemacht. Es wurden noch keine Sicherheitsaudits durchgeführt. Verwenden Sie auf eigenes Risiko.
Jedes Schlüsselwort in einer Suche oder Index ist tokenisiert. Dieses Token und der Tabellenname, in dem es vorkommt, sind mit Blake2b-128 gehasht und dann mit AES-128-ECB verschlüsselt, bevor sie für Anfragen gespeichert oder verwendet werden.
Encrypt(Hash(token + table_name))
Der ECB -Modus wird zur Verschlüsselung verwendet. Die ECB bewirkt, dass ein identischer Klartext identisch wird, aber dies ist kein Anliegen für eindeutige Werte wie den Hash eines Token- und Tabellennamens. Dies bedeutet, dass das gleiche Token einen anderen Chiffretext hat, wenn es in getrennten Tabellen auftritt.
Eine Dokument-ID wird mit AES-128-ECB verschlüsselt. Dies wird dann mit einem 32-Bit-Zähler verbunden.
Da eine Dokument-ID mehrfach erscheint und die Anzahl der Dokument-IDs weit kleiner ist als mit 128 Bits aufgezählt werden können, können die Dokument-IDs komprimiert werden.
Unter der Annahme von 1.000 eindeutigen Token / Dokumenten sind die Kosten für die Aufbewahrung der Vorkommen eines Tokens in den Dokumenten:
| Unterlagen | Unoptimiert | 32bit |
|---|---|---|
| 1000 | 16 MB | 4mb |
| 10k | 160 MB | 40 MB |
| 50k | 800 MB | 200mb |
| 100k | 1,6 GB | 400 MB |
| 250k | 4 GB | 1 GB |
| Million | 16 GB | 4 GB |
| Milliarde | 16tb | 4tb |
Die Differenzierung repräsentiert Werte in einer Sequenz als Differenz zwischen ihnen. Dies schafft Werte, die mit weniger Bits dargestellt werden können, die ein engeres Bitpacking ermöglichen.
Die Bitpackkiste wird zur Unterscheidung und Bitpackblöcke von 128 Ganzzahlen verwendet.
Die Differenzierung funktioniert am besten, wenn die Werte sortiert werden. Bei der Aufrechterhaltung sortierter und bitpackter Werte müssen jedoch alle Werte neu ermittelt werden, wenn ein außerordentlicher Eintrag hinzugefügt wird. Die Verwendung eines amortisierten Ansatzes mit einer Sammlung außerhalb der Bestellwerte kann die Kosten für Änderungen senken, indem sie abgeschrieben werden.
| Schichtzahl | Packungsprogramm | Sortierung | Verschiedenes |
|---|---|---|---|
| 0 | Keine - 32bit (<128 INTs) | Keiner | NEIN |
| 1+ | Bitpacker4x (128 INTs) | Weltweit amoung Schichten über 0 | Ja |
Rund 9.000 bis 10.000 kürzere Enron-E-Mails wurden komprimiert und die resultierende FTS-DB-Größe betrug 235 MB unter Verwendung einer 32-Bit-Codierung. Die Verwendung des amortisierten Unterschieds und der geschichteten Bitpacking änderte dies auf 21 MB.
Das Löschen einer Datei ist ... kostspielig ... Amortisation TODO
Todo erkunden. So etwas wie RocksDB -Memtable oder Schlitten. Speichern Sie Änderungen im Speicher und spülen Sie dann alle 500 ms oder wenn die Speichergrenze erreicht ist.
Eimer sortieren Wörter nach den ersten 3 oder 4 Zeichen (nicht tokenisiert), komprimieren? und verschlüsseln. Blockieren Sie Verschlüsselung mit etwas mit Diffusion wie CBC oder GCM (authinierte Verschlüsselung). Dies würde bedeuten, dass die Autokompetenz nach 3 oder 4 Zeichen eintreten würde. Dies befindet sich noch in der konzeptionellen Phase.
Die Datenintegrität ist optional, indem die Datenbankdatei in enger Zeit gehabt und eine verschlüsselte Version des Hashs gespeichert wird.
Es gibt keine Diffusion bei verschlüsselten Dokument -IDs. Das Hinzufügen von Diffusion erfordert Verschlüsseln von Dokument -IDs mit einem zufällig generierten IV. Dies würde auch Komprimierung unmöglich machen. Das Speichern der IV würde 128 Bit pro Token und Dokumentpaar (für AES CBC) hinzufügen.
Das Folgende ist für einen Angreifer ohne Schlüssel sichtbar:
Bei einem Index auf einer Patientenliste in einer Arztpraxis könnte ein Angreifer ohne Schlüssel die Anzahl der Patienten und eine Verteilung der in Dokumenten verwendeten Token sehen. Sie konnten keinen Klartext wie Namen oder andere Kennungen sehen, und sie konnten nicht einmal die Dokument -ID von Patienten sehen. Sie konnten sehen, ob zwei Patienten ein Such -Token haben, aber nichts darüber, wen die Patienten oder die gemeinsamen Informationen sind.
Wenn beispielsweise der Suchindex nur auf Namen in einem Land mit gemeinsamen Nachnamen wie Vietnam aufgebaut wurde, können Sie eine Frequenzanalyse durchführen und die wahrscheinliche Anzahl von Patienten mit dem Nachnamen Nguyen (38% der Vietnam -Bevölkerung) herausfinden. Dies stützt sich auf Ihre vorherige (Verteilung der Nachnamen), die für den vorliegenden Datensatz gültig sind. Es wäre auch nur gegen gebräuchliche Namen wirksam, was nicht identifiziert und wahrscheinlich nicht zuversichtlich Dokumente unterscheidet, die selbst den zweiten vom dritthäufigsten Familiennamen in Vietnam enthalten (Tran bei 11% und LE bei 10%).
Wenn noch einmal Informationen in den Suchindex wie Alter, Heimatstadt, Adresse, Beschreibung usw. hinzugefügt werden, verschwindet praktisch die Fähigkeit, Frequenzanalysen durchzuführen.
Ein Anliegen kann die Nicht-Repudiation von Speichern eindeutiger Datensätze sein, bei denen eine Frequenzanalyse eines großen bekannten Klartext-Datensatzes verwendet werden könnte, um zu zeigen, dass ein bestimmtes Gerät zweifelsohne indexiert war. Dies würde anscheinend nur Dissidenten in autoritären Ländern oder Kriminellen beeinflussen. Dies kann durch die vollständige Festplattenverschlüsselung gemindert werden, wenn das Gerät ausgeschaltet ist.
Sei d1 ein Dokument mit einem Token t1 . Sei t2 ein Token, dessen Hash mit t1 kollidiert und kein Token des Dokuments d1 ist.
Fehlalarme Aspekte, bei denen zusätzliche nicht verwandte Ergebnisse in ein Suchergebnis einbezogen wurden, können d1 auftreten, wenn die Suche t2 und nicht t1 enthält.
Falsch negative, wobei relevante Ergebnisse in einem Suchergebnis weggelassen wurden, können nur dann auftreten, wenn einer der kollidierenden Token für ein Dokument gelöscht wurde. Dies würde dazu führen, dass auch das andere Token "gelöscht" wird.
Fehlalarme oder Negative gelten nur für Dokumente mit einem der kollidierenden Token, wenn das andere kollidierende Token in der Suchabfrage vorhanden ist. Dies macht die Einsätze einer solchen Kollision sehr niedrig.
Das tatsächliche Risiko einer Kollision ist für 128 -Bit -Hashes komisch klein (siehe Geburtstagsproblem auf Wikipedia).
64 Bitverschlüsselung führt nur zu einigen Megabyte Space -Einsparungen für sehr große Indizes. Englisch hat ungefähr 1.000.000 Wörter und weniger Token. 64 Millionen Bit sind nur 8 MB. Angesichts der in Sprachen zu sehenen Verteilungen des Machtgesetzes, in denen die oberen hundert Wörter die Hälfte der Frequenz umfassen können, wären die tatsächlichen Einsparungen erheblich geringer.
