Gut, denn genau die angesprochenen Probleme sind auch meine Probleme
Vorweg, generell benötigst du in der Kryptographie Streams die nach Möglichkeit zwischernbuffern, sich überlappende Operationen ermöglichen und meistens nicht-seekable sind. Z.b. wird ein Buffer fester Länge verschlüsselt so entsteht meistens eine Expansion der Daten. Somit wäre ein Buffer als Ein-/Ausgabe sehr schlecht geeignet. Deshalb mein Konzept mit IDECStreams zu arbeiten. Das bedeutet aber das z.B. für Speicherbasierende Daten diese immer auch kopiert werden.
Oder zB. das Prozessing von verschl. Dateien. In einer solchen Datei muß der Cipher + Hash + PK-Algo. + Protokoll in der Lage sein im Header und Footer der Datei zusätzliche Daten abzulegen. Diese Daten müssen nun durch die verwendeten Algorithmen wieder lesebar sein, eben per Streams.
Oder ein Datenstrom soll nachdem er Komprimiert und Verschlüsselt wurde aus dem Binären Datenformat in ein MIME64 Datenformat konvertiert werden. Es gibt zwei Möglichkeiten. 1.) jeden Schritt für sich ausführen und somit mit vollen zwischenspeicherungen zu arbeiten, oder
2.) per teilgebufferten Streams arbeiten, die immer nur eine exakt austarierte Teilmenge der Daten buffern.
Ich würde 2. bervorzugen, da dadurch eben auch Livestreaming möglich wird. D.h. statt eines Datei-Streams an einem Ende des Streams sitzt ein Socket-Stream. Deshalb eben auch das Konzept einen eigenes Daten-Interface zu basteln. Diese Streams besitzen im Grunde keinerlei Operationen für's Seeking, Size, Position etc. sondern arbeiten per EOF/BOF,Read,Write. Meistens sogar wird so ein Stream nur in einer Richtung funktionieren, also Writeonly=Sink oder Readonly. Alle Algorithmen Objecte arbeiten nun nur auf solchen Datenstreams. Damit benötigt man eben in den Ciphern zB. keine mehrfachmethoden wie .EncodeString(), .EncodeBuffer(), .EncodeStream(), .EncodeFile() sondern eben nur .Encode(const Source: IDECReadStream; const Dest: IDECWriteStream);
Diese Streams werden nun sequentiell in .Encode() ausgelesen in einen Buffer. Dieser wird durch an das interne Cipher-Algo-Interface weitergeleitet und verschlüsselt.
Performance ist schön und gut, aber steht immer im Gegesatz zu einem universellen und flexiblen
API Design.
Das ganze
API bestünde also aus dem IDEC Interface das sozusagen als Manager und Allokator der IDECCipher/IDECHash Interfaces dient. Alle Daten werden in ein einheitliches Interface gekapselt. Dies Kapselung hat im Usercode zu erfolgen. Für Delphi/BCB würde man diese schon vorfertigen.
Hier alle Sourcen darzustellen geht aber zu weit, besonders weil ich selber schon x'mal das komplette Design umgeworfen/verworfen und neuangefangen habe. An irgendeiner Ecke hackt es dann immer wieder. Es ist im grunde ineffizient als Einmann-Team, ohne konstruktive Diskussionen, ein solches
API und Konzept aufzubauen.
Gruß Hagen