Performance Ent-/Verschlüsselung großer Dateien

[jaikai]

Hi Leute,

die Daten meines Kunden muß ich verschlüsseln.

Zustand vorher:
String-Datei lag im Klartext vor. (Nur Text)
In meinem Such-Algorhythmus im Klartext (Ansipos) dauerte die Suche nach irgendwelchen Teilen daraus höchstens 1,5 sek.

Verschlüsselung:
Dann hab ich Teile der String-Datei mit dem RC6 Algorhytmus verschlüsselt, wobei ich mir nicht sicher bin, ob er langsam oder schnell ist. Ungeachtet dessen reicht es von der Performance her aus, soweit die Dateien und Inhalte "eben kleiner" sind.

Jetzt Zustand:
Performance-Einbruch total. Die Suchdauer liegt jetzt irgendwo jenseits 3 Minuten und ist völlig unakzeptabel. Ob ich nun Teile oder komplett verschlüssele - ist egal. Is einfach zu langsam( gibts eigentlich ne Steigerung davon?)
Ich kann aber auch nicht einfach das Suchwort verschlüsseln und wieder mit Pos/AnsiPos suchen. Also hätte ich nötig, jeden String einzeln zu entschlüsseln und dann erst zu prüfen.

Frage:
Gibts denn dafür keine schnelleren Methoden? Wie bekomme ich die Performance wieder in den Griff? hat irgenjeman einen Ansatz für mich?

Danke

[marabu]

Hallo.

Leider hast du keine Aussage zur Datenstruktur und der Speichertechnik (Textdateien? Oder doch eher ein RDBMS?) gemacht. Auch eine Beschreibung der Suchfunktionalität wäre interessant. Grundsätzlich hilft eine Anonymisierung, bei der personenbezogene Kundendaten von Transaktionsdaten getrennt werden. Oft müssen dann nur noch spezielle Informationen verschlüsselt werden, die niemals im Rahmen von Mengenoperationen, sondern nur bei Direktzugriff entschlüsselt werden müssen. Ein Performanzproblem durch Schlüsselroutinen tritt so garnicht mehr auf.

Grüße vom marabu

[jaikai]

Also -

Die Textdatei ist eine echte Textdatei, keine Datenbank, kein RDBMS...
Die alte/neue Methode war "InputListe.LoadFromFile()". Aus der Textdatei wird nur gelesen, nix geschrieben, nix geändert.

Beispiel:
26:00097498:ElqVDS+YMuVgzdjLQouYOQjTDwo= (= Kodierung für Icon, Kodierung für Anzeige, Text)

Normale Suche für Klartext, Dummystring ist nur getauscht gegen die Rückgabe der Entschlüsselung.

Delphi-Quellcode:

if trim(ComboBox_Suchen.text) <> '' then begin
   if trim(ComboBox_Suchen.text) = Sprachnummer(341) then              // Alle ( 12 MB File!)
      InputListe.LoadFromFile( Suche_Dir + 'VOLLTS.txt');            // 341 = Alle Kapitel
   if trim(ComboBox_Suchen.text) <> Sprachnummer(341) then
         InputListe.LoadFromFile( Suche_Dir + 'VS_' +  trim(ComboBox_Suchen.text) + '.txt'); 

   ...  
   S_1 := trim(Ansilowercase(Search_1.text));
   S_2 := trim(Ansilowercase(Search_2.text));
   for i := 0 to InputListe.count -1 do begin
        Dummystring := Ansilowercase(Entschluesseln(CodeB, copy(InputListe.strings[i], 13,
                                                         Length(InputListe.strings[i]) - 12)));
   ...
   // folgt der Vergleich und was damit zu tun ist

Habe zwar auch Luckies Versionen getestet (auch mit Klartext)
http://www.delphipraxis.net/topic65395_datei+im+speicher+zeilenweise+lesen.htm l&highlight=zeilenweise

allerdings ist die Performance ziemlich gleich, da war mir die VCL bequemer.

So - und jetzt frag ich mich, wie kann man 25 MB Daten entschlüsseln und checken könnte, ohne daß man zwischendurch Kaffee kochen gehen kann?!?

Okay?

[marabu]

Wenn deine Textdatei eine dreispaltige Tabelle darstellt, dann würde ich sie nach dem Einlesen sortieren und anstatt jeden Eintrag zu enstschlüsseln würde ich den Suchbegriff verschlüsseln und per IndexOf() suchen. TStringList (binary search) oder auch die THashedStringList sollten die Suche recht flott erledigen. Oder hast du noch andere wichtige Informationen zurückgehalten?

Freundliche Grüße vom marabu

[jaikai]

Hi marabu,

Die Ergebnisse der Suche kommen tatsächlich in ein S'Gring, aber das halte ich nicht für eine "wichtige Information". Nach ner Suche hat man halt immer ein Ergebnis. :)

Den Suchbegriff kann ich nicht verschlüsseln, weil der 'Output' anders lautet wie der in dem Suchstring steckende, denn der bildet eine Aneinandereihung von Begriffen. Alles schon ausprobiert, das hakt aber. (TextString: "Kopf, Augen, blind, iris, pupille, kann nix sehen...") der verschlüsselte (auch wenns nur Begriff "Augen" wären, sieht innerhalb anders aus, als nur ein verschlüsselter SuchBegriff.

Da ist hashed und binary - so glaub ich - nicht der richtige Ansatz. Wo der Suchbegriff zu finden ist, kann nicht vorrausgesagt werden (erster oder auch letzter Pseudodatensatz). Immerhin liegen die Daten, die es zu finden gilt ja gar nicht in Klartext vor. Die heißt es ja mit einer entsprechenden Performance umzuwandeln. Und genau da such ich eine bessere Lösung.
Dine Vorschläge dürften öllisch schnell für Klartexte sein...

Danke

[shmia]

Du könntest die verschlüsselte Datei wieder entschlüsseln und in eine neue Datei schreiben.
Damit dabei keine Sicherheitlücke entsteht, muss folgendes beachtet werden.
Die Klartext-Datei wird mit der API-Funktion CreateFile erzeugt.
Du verwendest die Flags CREATE_ALWAYS, keine Share-Attribute, sowie FILE_ATTRIBUTE_HIDDEN|FILE_ATTRIBUTE_TEMPORARY.
Danach verwendest du THandleStream um bequem mit der Datei arbeiten zu können.
Solange du das Handle in Besitz hält, kann kein anderer Prozess die Datei auslesen.
Bevor du das Handle mit CloseHandle schliesst, machst du den Inhalt kaputt mit SetEndOfFile.
Wegen FILE_ATTRIBUTE_TEMPORARY wird die Datei wahrscheinlich gar nie auf der phys. Platte gespeichert.

[marabu]

Die besten Algorithmen versagen, wenn die Daten nicht kompatibel sind. Wenn du darfst und kannst, dann versuche die Datenorganisation zu verbessern. Ansätze dafür habe ich dir schon gegeben, auch was den Datenschutz betrifft. Außerdem verschwindet dann die Redundanz für deine Gesamtdatei. Eine Beschleunigung deiner brute force Suche wird nicht mehr viel reißen. Jeder Laufzeitgewinn wird durch die Datenzuwachsrate eventuell gefressen. Selbst wenn du die Geschwindigkeit um den Faktor 10 erhöhen kannst - was ich nicht glaube - erzielst du bestenfalls 18 Sekunden anstelle 3 Minuten Antwortzeit. Mit einer index-basierten Lösung kommst du leicht unter das Standard-Limit von 2 Sekunden.

Viel Erfolg.

marabu