Delphi Encryption Compendium

[Daniel Göhl]

Hallo Hagen, <BR>
<BR>
ich habe mir die oben genannte Komponente aus dem Internet gezogen, in meinem Delhpi 5 installiert und das beiligende Demo Program angeguckt. Soweit so gut. Also mein problem ist das ich einen record verschlüsseln möchte. Da ich diesen später über eine Netzwerk verbindung schicken möchte speicher ich diesen in einem Stream. So nun kommt das Problem. <BR>
<br>
procedure TForm1.Button1Click(Sender: TObject);<br>
var<br>
KlarStream, encodeStream, decodeStream : TStream;<br>
s1, s2, s3 : String;<br>
begin<br>
KlarStream := TMemoryStream.Create;<br> EncodeStream := TMemoryStream.Create;<br> DecodeStream := TMemoryStream.Create;<br>
M1.Lines.SaveToStream(KlarStream);<br>
cipher.InitKey(edit1.Text, nil);<BR>
cipher.EncodeStream(KlarStream, EncodeStream, KlarStream.Size);<BR>
cipher.DecodeStream(EncodeStream, DecodeStream, EncodeStream.Size);<BR>
EncodeStream.Position := 0;<BR>
DecodeStream.Position := 0;<BR>
memo1.Lines.LoadFromStream(encodeStream);<BR>
memo2.Lines.LoadFromStream(decodestream);<BR>
end;<br>
<br>
Diese Zeilen funktionieren nicht. Ich wollte der einfachheit halber das alles erstmal mit Strings versuchen befor ich mein record da durch jage.
Wenn ich die Obigen Zeilen ausführe bekomme ich keine Ausgabe in Memo1 und Memo2. Die bleiben Leer. <br>
Es wäre schön wenn du mir auf die Sprünge helfen könntest!! Vielen Dank!<br>mfg<br>
<br>
Daniel<br><br>
PS: Kann ich die Version 3.0 deiner Komponente auch in Delphi 6 Installieren??

[Hagen Reddmann]

Hi Daniel

Jedes Speichern und Laden in einem Stream verschiebt die Position/Dateizeiger im Stream. Angenommen ein leerer MemoryStream. Mit .Write(Data, 1024) schreiben wir 1024 Bytes rein. Dann ist MemoryStream.Position := 1024. Ein nachfolgendes Laden mit .Read(Data, 1024) wird nun NICHT die original Daten laden sondern versuchen 1024 Bytes von der aktuellen Position und die ist ja gerade 1024.<br>

Kurz gesagt: Nach M1.Lines.SaveToStream(KlarStream) kann Cipher.EncodeStream() NICHT auf die gerade gespeicherten Lines zugreifen, da KlarStream.Position HINTER die gespeicherten Lines zeigt.<br>

Lösung:
a.) vor Cipher.EncodeStream() mal KlarStream.Position := 0; setzen.
b.) oder Cipher.EncodeStream(KlarStream, EncodeStream, <b>-1</b>); <br>

wenn im .EncodeStream() als Size = -1 eingesetzt wird, wird intern der komplette Stream verschlüsselt, also intern wird Stream.Position := 0; gesetzt.<br>
Gleiches gilt auch für Dein .DecodeStream() Aufruf.<br>
Die Sache ist doch eigentlich logisch: Beide Funktionen können nicht einfach an Position = 0 seeken, es könnte ja sein das Du z.B. erst ab dem X'ten Byte Count Bytes verschlüsseln willst, also nur einen Ausschnitt aus den daten. Deshalb ist der Anwender für die korrekte Positionierung verantwortlich, wie übrigens bei ALLEN Stream Operationen. Vor Memo1.Lines.LoadFromStream() hast Du doch auch die Repositionierung vorgenommen, un En/DecodeStream arbeiten genauso wie Lines.LoadFromStream().<br>

DEC und D6:<br>
Ja, mit einer kleinen Änderung in Unit DECReg.pas in der Uses Klausel. Es wird die Unit "DsgnIntf" durch "DesignEditor, DesignIntf" ersetzt. Das wars dann. Diese Änderung MUSS übrigens bei allen Komponenten getätigt werden, und liegt halt daran das Borland zum X'ten mal einfach Unit's umorganisiert. Für eine Zukunftsorientierte Planung in einem Projekt ist dieses Verhalten von Borland absolut schädlich, und es gibt einige Manager die daraufhin sofort auf Delphi verzichten würden.<br>

Gruß Hage

[Daniel Göhl]

Hallo Hagen, <BR>
<BR>
vielen Dank für deine Hilfe. Das mit den STreams funktioniert jetzt. Das mit Delphi 6 leider nicht. Ich habe die Unit 'DsgnIntf' durch 'DesignEditor' und 'DesignIntf' ersetzt. Dann sagt mir der Compiler er würde die Datei DesignEditor.dcu nicht finden. Muss ich dazu ein bestimmtes Packet installiert habe?? Ich habe nämlich ein bisschen auf Sparflamme installiert. Wenn ich 'DesignEditor' nicht in die USES clausel eintrage gibt der Compiler die Fehlermeldung '[Error] DECReg.pas(27): Undeclared identifier: 'TStringProperty' ' aus. <br>
Dann habe ich noch eine Frage. Ich kenne mich noch nicht mit der Krypthographie aus. Ich habe hier im Forum einen Beitragg gefunden in dem du Bücher empfielst. Ich werde sie mir zu gemüte führen.<br>
Im moment muss ich jedoch noch dumme fragen stellen. Also, was hat das mit dem HASH auf sich?? Wenn ich mit dem Cipher einen Stream verschlüsseln möchte brauche ich den HASH doch nicht, oder?? Mich würde einfach mal interessieren wozu das gut ist.<br>
<br>
Vielen Dank im vorraus<br>
<br>
Danie

[Hagen Reddmann]

Hi<br>

DEC und D6: Die datei DECreg.pas MUSS in einem Laufzeitpackage z.B. wie "Borland Benutzer Komponenten" installiert werden. Dieses Package muss dann auch das DesignTime Package beinhalten. Diese Restriktion ist auch eine "Borland Neuerung", die besagt das nun ALLE Packages die mit dem DesignTime Interface arbeiten selber DesignTime Packages sein MÜSSEN und somit nur noch AUSSCHLIESSLICH mit der Delphi IDE funktionieren.<br>

Am besten Du mail'st mir Deine E_Mail Adresse an mailto:[email protected] dann kann ich Dir mein D6 Part I vom DEC mailen.<br>

Hash-Algorithmen: sind Algorithmen die einen beliebigen Datenstrom in einen Wert=Digest umwandeln der immer eine feste Länge hat (Hash.DigestKeySize) und dieser ist mit sehr hoher Wahrscheinlichkeit immer eindeutig zu den Inputdaten. Heist ein bestimmter Digest kann nur mit ganz bestimten Daten erzeugt werden, und wird nur EIN Bit der daten geändert MUSS ein komplett anderer Digest entstehen. Die Zweite wichtige Eigenschaft eines Hashs, ist das von einem Digest NIEMALS auf die dazugehörigen Daten zurückgerechnte oder nur annähernd irgendwelche Informationen über die daten zu berechnen sind. Konkret sind hashfunktionen also "Ein-Weg-Funktionen" oder fachspezifisch ausgedrückt "secure One-way-functions". Interessant ist das alle Mathematiker vor 20 Jahren der Meinung waren das es solche Funktionen überhaupt nicht geben KANN <br>

Zur Verschlüsselung mit einem Cipher benötigt man normalerweise keine Hashfunktion. Es ist aber immer ratsam eine User-Passwort mithilfe eine Hashfunktion in ein real benutztes Session-Passwort zu konvertieren. Das hat mehrere Gründe. Die Entropie eines normalen, lesbaren Passwortes ist sehr schlecht. Wenn pro Stelle im Passwort 256 mögliche Zeichen existieren, so werden in unserer Sprache nur 26 Buchstaben, 10 Ziffern und ~4 Sondernzeichen davon benutzt. Also nur ~ 1/6'tel aller verfügbaren Zeichen werden tatsächlich benötigt. Ein solches 12 Zeichen Passwort wäre so sicher wie ein Zufallsbytearray mit 2 Bytes größe !! Nun, durch die hashfunktion wird die benutzte Entropie nicht vergrößert, aber deren Verteilung wird verbessert. Und sollte es nun einem Angreifer gelungen sein zu entschlüsseln, dann findet er den Hash-Digest als Sessionkey aber NICHT das tatsächlich benutzte Passwort ! Das sichert also den User enorm ab, da dieser ja das gleiche Passwort als SafeNummer + KontoPIN + OnlinePassort usw. benutzt. Ohne eine hashfunktion ist die gefahr das ein Hacker dann das lesbare Passwort findet und somit auch an's Konto + Online + Safe des Users kommt.<br>

In DEC wird mit TCipher.InitKey() genau eine solche Hashbasierende Transformation des Passworts in den SessionKey automatisch vorgenommen.<br>

Gruß Hage

[Daniel Göhl]

Hallo Hagen<BR>
<BR>
Vielen Dank für deine schnelle Antwort. Ich habe das Grundprinzip verstanden, und habe lust auf mehr bekommen. Ich werde dir eine eMail mit meiner Adresse schreiben.<BR>
<BR>
mfg<BR>
<BR>
Danie

[Tim Henford]

Hallo,

kennt jemand "schon" das neue AES-Verschlüsslungsverfahren und wie sieht es eigentlich mit Volume II des Kompendiums aus?

Tschüss Ti

[Hagen Reddmann]

Im DEC part I sind 4 von den 5 Final Round kandidaten enthalten. Rijndael ist der "Sieger", was schon erstaunlich ist, da Rijndael KEIN US-Amerkiansicher Cipher ist. Heist: DEC part I enthält Rijndael, Mars, RC6 und Twofish.<br>

Part II,III,IV sind in Arbeit, aber viel komplexer als part I. Part's II Basis ist fertig, und mehrere asymmetrische Cipher sind fertig. RSA,HD-RSA,BBS-RSA,P2Q-RSA,ElGamal,DH,RW,XTR uvm. Folgen müssen noch die ECC's. Zugunsten vom Part II habe ich die Arbeiten an III und IV reduziert. Heist die Outer-Protokolle wie PKCS#, OpenPGP,PEM und S/MIME müssen noch warten. Dies ist aber nicht allzu tragisch da die Algorithmen aus Part II eh schon kompatibel sind.<br>

Gruß hagen

PS: allerdings werden die nachfolge parts eben ein kommerzielles produkt