Einzelnen Beitrag anzeigen

Benutzerbild von negaH
negaH

Registriert seit: 25. Jun 2003
Ort: Thüringen
2.950 Beiträge
 
#94

Re: Dateien verschlüsseln - aber wie?

  Alt 14. Okt 2003, 15:29
Zitat:
Wie ist das denn beim neuen DEC? Baust du da Funktionen ein, die leichter zu verwenden sind? Dann würde ich dich auch bitten, dass du den Funktionen auch die Eigenschaft OnProgress zuweist.
Und es sollte eben auch so sein, dass keine Temp-Datei geschrieben wird. Eine Festplatte ist ja schließlich kein Arbeitsspeicher.
Kleinere Streams oder so kannst du ja auch problemlos in den Arbeitsspeicher auslagern, aber eben schlecht größere Dateien.
Bis zum Wochenende habt ihr die neueste Version.
Darin enthalten sind die neuen Registrations Funktionen die auch dafür sorgen das man die Identity benutzen kann um sie in Stream zu speichern.
Ich baue auch ein Skelett für die Benutzung der Ciphers zur Verschlüsselung von Stream's mit ein die zusätzliche Headers enthalten. Allerdings die Verschlüsselung/Entschlüsselung einer Datei läuft immer über eine zusätzliche neue Datei ab. Das hat mehrere Gründe. Man könnte auch eine inplaced Datei-Verschlüsselung coden, diese würde aber enorm kompliziert werden, da durch die zusätzlichen Header sich die Dateigröße vergrößert. Man muß dann per temporären Buffern und interleaved Read/Write Operationen arbeiten.

Das OnProgress Event wird nicht mehr benutzt, da es nicht Threadsafe ist. Ich denke darüber nach die Skelett Funktionen durch ein IProgress-Interface auszubauen. Dieses kann dann den Funktionen übergeben werden.

Allerdings, eines ist jetzt schon klar: das neue DEC ist eine Neuentwicklung und keine direkte Nachfolgerversion vom DEC v3.0. Es wurden sehr viele Sachen geändert, entfernt oder hinzugefügt:
- nur noch ab Delphi 5 lauffähig, da overloads usw. benutzt werden
- Klassen Hierarchie wurde abgespeckt, TProtection gibts nicht mehr
- DEC's Exception's wurden abgespeckt, es gibt nun nur noch EDECException
- Klassen Registration wurde aus DEC v4.0 übernommen und ist einheitlich, zusätzliche Enum Functions
- TString_Format Klassen wurden in eigene Unit ausgelagert und vollständig überarbeitet
- Neue Hash-Algorithmen SHA256,SHA384,SHA512,Panama,Whirlpool 0/1
- alle Hash-Algo's nutzen Tol's optimierte Assembler Umsetzungen, im gesamten sind alle Hash somit ca. 80% schneller
- Cipher wurden alle überarbeitet, und so einige gravierende Fehler beseitigt
- es wurden neue wichtige Ciphermodis hinzugefügt, z.B. cmCFBx, cmOFBx, cmCFSx, cmCFS8
- Modus cmCFBx mit Blowfish verwendet ist identisch mit dem offiziellen CFB64 Modus
- alle Cipher arbeiten nun nicht mehr zwingend inplaced, was mit geänderten Ciphermodis dazu führt das zB. Blowfish 40Mb/sec statt 30Mb/sec oder Rijndael 47MB/sec statt 38Mb/sec schnell sind.
- alle SelfTest's wurden entfernt und müssen durch ein externes Projekt verifiziert werden, dies spart enorm Resourcen, und ist eigentlich auch sicherer.
- die Cipher arbeiten beim Keysetup im Standardmodus, d.h. die Cipher machen nun keine Umwandlung des Paswortes per Hashfunktion in einen Sessionkey mehr. Dies ist nun Aufgabe des Programmierers. Der Grund ist das besonders diese KDF's (Key Derivation Functions) sich weiterentwickelt haben und es dem Programmierer überlassen bleiben muß wie der das Passwort konvertiert. Zusätzlich werden die Cipher's dadurch von Aufgaben entlastet die nicht zu ihnen gehören.
- bei ALLEN Algos wurde strikt darauf geachtet das wenn sie NICHT benutzt werden auch GARNICHTS zusätzlich in die EXE eingelinkt wird. D.h. der Compiler/Linker kann jederzeit alle Daten/Tabellen usw. die zu einem Algo gehören, der nicht benutzt wird, wegoptimieren. Benutzt man z.B. nur Rijndael + SHA so werden nur ca. 16Kb eingelinkt.
- neue zusätzliche Units:
- CRC.pas um eine universelle CRC Checksum Library zu haben, mit ihr können ALLE möglichen 2-32 Bit CRC's erzeugt werden
- CPU.pas eine Unit zu Ermittlung der CPU Daten + CPU Speed
- alle TRandom Klassen wurden entfernt

Fehlen tut jetzt noch:
- Hash MAC's
- RFC2289 Konvertierungen
- DEC eigene KDF die die schlechte IEEE KDF1 ersetzen könnte
- eventuell packe ich noch meine sehr effiziente LZH Komprimierungs Unit mit rein
- Ersatz des enifachen Zufallsgenerators durch einen YARROW ähnlichen sicheren Zufallsgenerator. Dieser kann dann als AddOn direkt den integrierten RNG ersetzen.



Gruß Hagen
  Mit Zitat antworten Zitat