Zu den TComponent Varianten der Cipher:
Davon halte ich überhaupt nichts. Frage dich wann eine solche Komponente erzeugt wird und wie lange sie lebendig ist. Nun frage dich wie lang die Zeitspanne ist in der man sicherheits relevante Aufgaben erledigen muß.
Und nun, nachdem du festgestellt hast das eine Komponnete quasi die ganze Zeit aktiv ist und die Sicherheitsaufgabe im Program aber nur wenige Millisekunden zu dauern hat, fragst du dich warum es sicherer sein muß die Zeitspanne in der man Kryptographie im Program benutzt so kurz wie nur möglich zu halten.
Es ist ein kryptographsiches Sicherheitsrisiko ein Passwort und den initialiserten Cipher als Komponnete die ganze Zeit in der ein TForm offen ist, im Speicher zu halten. Damit bietest du Trojanern nur unnötige Angriffsziele und auch den notwenigen Zeitraum dafür.
Zudem macht eine Komponente dann ganzen Kram nur noch unübersichtlicher. Im Normalfalle möchtest du zb. eine Datei verschlüsseln.
Also wählst du
1.) den Cipher deines Vertrauens
2.) den Cipher Modus deines Vertrauens
3.) den Hash deines Vertrauens
aus und baust dir zwei simple Funktionen:
procedure EncodeFile();
procedure DecodeFile();
und allozierst innerhalb dieser Funktionen deinen Cipher deines Vertrauens, wandelt das Password mit einem Zufallssalt und einem Hash deines Vertrauens, zb. mit THash_SHA1.KDFx(), in einen sicheren Sessionkey um, initialisierst damit den Cipher nachdem du diesen mit dem Cipohermodus deines Vertrauens initialisert hast und verschlüsselst/entschlüsselt die angegebene Datei. Fertig. Zwei simple Funktionen, 1 Cipher, 1 Hash und mit minimalstem Aufwand steht das System.
Das nun in
DEC so viele verscheidene Algorithmen drinnen sind hat nur einen Grund
Sicherheit
genauergesagt Verfahrenssicherheit. Das beduetet das du ohne großem Aufwand in Zukunft wenn der Cipher deines Vertrauens eben nicht mehr vertrauenswürdig ist, auswechseln kannst.
Es besteht überhauptnicht die Notwendigkeit in einer Software hunderte verschiedener Verschlüsslungen dem Benutzer anzubieten. Nein, ich sehe das eher als eine Unfähigkeit des Entwicklers sich nicht entscheiden zu können und deshalb alles was möglich ist anbietet. Das ist unseriös.
Denoch: schaue mal ob du die alte Version 3 oder früher bekommst. Darin sind die Komponenten TCipherManager und THashManager integriert (als DEMO wohlgemerkt)
Denn anstatt nun 100 Komponneten zu erzeuge, jeweils zb. TCipher_Rijmdael_Component und TCipher_Blowfish_Component und TCipher_IDEA_Componet reicht eine EINZIGSTE TCipher_Componnet vollkommen aus in der man den zu benutzenden Algo. auswählt.
Ehrlich gesagt hasse ich das. Man kann aus allem eine Komponnete machen, sogar aus ShellExecute(ProgrammName) aber ich bezweifle ob so ein Übereifer eine wirklich nützliche Sache darstellt.
So, das soll jetzt keine Ablehnung meinerseits darstellen, ich helfe jedem gerne. Ich möchte dir aber aufzeigen warum ich eben meine Bibliothek so gecodet habe und nicht anders. Und ehrlich gesagt bin ich auch ein bißchen stolz darauf das
DEC so viele gute Kritiken im WEB bekommen hat. Das liegt eben auch daran das sich das
DEC auf das eigentliche Ziel konzentriert: eine kompakte auf das Notwendigste und denoch in Zukunft flexible Bibliothek zu sein. Um das zu ereichen muß man sich auf die minimalste Schnittstelle einigen die die geringsten Abhängigkeiten in ZUkunft zu erwarten hat. TComponnet ist keine solche Schnittstelle. Wenn die
VCL irgendwan ausgestorben ist so wird man
DEC immer noch in irgendeinem FreePascal zum laufen bekommen, eben weil es sich auf das Wesentlichste beschränkt.
Nun Komponenten sind sehr einfach zu benutzen, das ist unbestritten und gerade das macht mir Sorgen. Denn
DEC ist keine readymade Software sondern eine Bibliothek. Der Benutzer vom
DEC muß sich also immer intensiv mit Kryptographie beschäftigen damit er
DEC auch sicher benutzen kann. Eine TComponent würde auch von den sogennaten "Drag&Design" Programmieren benutzt werden ohne das sie überhaupt wissen was sie da tuen. Das ist ein Sicherheitsrisiko und ich möchte nicht mit meinem Namen in der Copyright Box einer solchen Anwendung drinnenstehen.
Im alten
DEC hatte ich wie gesagt zwei Komponneten drinnen. Diese waren eigentlich nur als Demo für spezielle Funktionen im
DEC angedacht und brachten mir in den folgenden 2 Jahren nur Ärger ein. Ständige EMails von Supportanfragen in denen ich darauf verweisen musste das es eine schlechte Idee ist diese Komponenten zu benutzen.
Da alle TCipher von einer Basisklasse abgeleitet wurden und demzufolge in ihrem Interface fast 100%'tig zueinander identisch sind wäre es Dummheit nun all diese Klassen in jeweils eigene Komponneten zu verfrachten. Diese Zeit hätte ich nicht und im Grunde versuche ich eine Arbeit nur einmal und nicht 100'mal zu machen. Ergo: wenn eine Komponente dann kapsel darin die Auswahl der TCipher Klasse pere Namen oder Dropdown Liste quasi als Property dieser Komponente. So brauchst du ur 1 Komponente erstellen die mit allen TCipher Klassen arbeiten kann. Das macht zb. für eine
TPasswordProtectionComponnet oder TFileEncrytionComponnet oder TStreamEncryptionComponnet durchaus Sinn. Bei diesen Komponneten bestimmt deren Aufgabe ihr Design und meine TCipher Klassen sind nur auswählbare Eigenschaften dieser Komponenten. Das heist auch das erst zum wirklich wichtigen Zeotpunkt und auch nur für die Dauer dieser wichtigen Operation ein TCipher erzegt wird und gleich wieder zerstört wird durch diese Komponenten. Und ich würde mch sogar freuen, da ich nun bei der nächsten Frage wie man sehr einfach mit
DEC ein Passwort schützen kann auf deine TPasswordProtectionComponet verweisen kann
Gruß Hagen