Delphi Encryption Compendium

[Mark Nemoz]

Hi ihr

ich steh bei meinem Prob irgendwie total aufm schlauch und hab leider gar keine ahnung davon wie ich das teil in Delphi installieren muss!!! die demo geht leider net weil TCipher etc. nicht da sind... (

also bitte hilfe =))

[Mark Nemoz]

lol nee habs schon gefunden sorry für meine beiden trottel fragen ;

[Hagen Reddmann]

<li>Cipher.zip mit Directories entpacken
<li>Delphi\Menu\Komponente\Installiern.. ausführen
<li>Unit DECReg.pas in "Name der Unit.." auswählen
<li>am besten ins Borland Benutzer Package installieren
<li>diese Package neu compilieren und dann installieren
<li>es erscheint die Meldung "es wurden X Komponenten installiert"
<li>im Reiter "DEC" findest Du 3 Komponenten<br>

Um es in D6 installieren zu können müssen 3 Änderngen vorgenommen wwrden<br>
<li>In Unit DECReg.pas in der Uses Klausel "DsgnIntf" mit "DesignIntf, DesignEditors" ersetzen. Borland macht es Entwicklern nicht gerade leicht
<li>In unit DECUtil.pas in der initialization Sektion folgende Zeile ändern <b>InitTestIsOk := CRC32($29524828, GetTestVector^, 32) = $9B497502;</b>
<li>falls Unit Checksum vorhanden ist dann folgendes abändern:
<pre>

procedure TChecksum_CRC.Calc(const Data; DataSize: Integer); assembler;
asm
JMP DWord Ptr [EAX].FProc.TMethod.Code
end;

</pre>

Gruß und viel Spaß, Hagen<br>

PS: ich empfehle Dir auf die Komponenten TCipherManager/THashManager zu verzichten und nur die nativen TCipher_XXXX/THash_XXXX Klassen zu nutzen

[Al Kohol]

<b>PS: ich empfehle Dir auf die Komponenten TCipherManager/THashManager zu verzichten und nur die nativen TCipher_XXXX/THash_XXXX Klassen zu nutzen.</b><br>

warum

[Hagen Reddmann]

weil sie einfach überflüssig sind und die Sache eher verkomplizieren. Grundsätzlich habe ich diese sowieso nur gecodet damit das DEC wenigsten 2 sichtbare Komponenten besitzt. DEC ist im grunde ein Bibliothek wie Delphis SysUtils oder StrUtils oder Math usw. halt eben nur für kryptographische Belange.<br>

Beide Komponenten stellen zusätzlich noch ein Sicherheitsrisiko dar, nicht weil man eine Komponente eg. Formularresource leichter analysieren kann, sondern weil die Lebenszeit der in der Komponente verwaltenten Object (Hash/Cipher) wesentlich länger ist als nötig. Nutzt man dagegen direkt die TCipher/THash Klassen werden diser erst bei Bedarf erzeugt, mit dem Passwort versehen, dann deren Operation durchgeführt und gleich wieder zerstört. Dies ist sicherer.

Gruß Hage

[Al Kohol]

danke für die infos <br>
ist schon geil, die infos direkt vom "hersteller" zu bekomme

[Robert Marquardt]

Hagen, TOndrej arbeitet an einem Jedi Uses Wizard, der die Fehlermeldungen analysiert und entsprechend units im uses nachtraegt. Das macht solche Komponenten ueberfluessig, die eigentlich nur da sind um beim Droppen die unit ins uses einzutragen

[Hagen Reddmann]

Das ist aber eine gute Idee. Interessant wird es WIE TOndrej ermitteln will welche UNIT denn nun fehlt

[Robert Marquardt]

Das Ganze ist fuer die Jedi Code Library gedacht. Man kann also das noetige Mapping in Form von einfachen Textdateien von Hand erstellen. Solche APIs aendern sich nur langsam. Entsprechend kann man die Dateien fuer die VCL auch erstellen. Vielleicht findet sich auch jemand, der .dcu files analysieren kann, dann kann man das auch noch automatisieren

[Hagen Reddmann]

Es gibt schon einen DCU Decompiler als Source. Ich schau mal ob ich ihn wiederfinde. Es wäre nämlich ziemlich zeitaufwendig alle Bezeichner aus einer Unit manuell in eine DB einzupflegen

[Robert Marquardt]

So schlimm ist das nicht mit dem Einpflegen. Wir sollten den Thread mit privatem eMails weiterfuehren. ([email protected]). Ich kann dir dann auch die bisherigen Stand des Wizards schicken. Der hat ein paar lustige Sachen. Z. B. addiert er ein Registerblatt zu den globalen Optionen

[Hagen Reddmann]

Genau, einzigster Nachteil der Manager ist das eine Liste der auswählbaren Cipher/Hash registriert werden muß. Das heist auch das ALLE im Cipher/HashManager auswählbaren Algorithmen und deren Code in die EXE eingelinkt werden. Normalerweise benötigt man 1-2 Hashalgos. und 1-2 Cipheralgos. DEC enthält aber im vollem Umfang ca. 40 Cipher und 23 Hashalgos. Das für sich genommen bläht die EXE größe um ein mehrfaches auf.<br>
Fazit: egal wie man es dreht und wendet, die Manager Komponenten sind uneffizient, eigentlich umständlich und nur für die DAU's unter uns, den Drag&Design-only-Codern eine gute Alternative.<br>
Für die Neueinsteiger in diesem Forum zur Erklärung, die Software um die es geht und die ich hier so unsanft kritisiere ist meine eigene <br>

Gruß Hagen

alle 40 Cipher und 23 Hashs und die anderen Klassen benötigen ca. 800Kb, und das ist ziemlich viel für die meisten Sicherheitsanforderungen. Nicht die Masse machts sondern die Qualität der Nutzung der DEC Objecte

[Hagen Reddmann]

Jo, es gibt Librarys die dies machen. Aber warum ? Wenn man gleich die Cipher/Hash Klassen benutzt ist das schneller, übersichtlicher und spart den VCL Overhead.<br>
Ich habe mich eh schon entschieden auf solche Komponenten zu verzichten. Das liegt auch darin begründet daß ich vielleicht mal Kylix unterstützen möchte, in D7 weniger Probleme mit dem DesignTime Interfaces bekommen möchte (siehe Probleme von D5 auf D6) und eventuell möglichst einfach die zukünftigen .NET Features von D7? nutzen möchte.<br>

Gruß hage