DEC -- ENCODE('Passwort',nil) -- welchen Schlüssel verwende ich ?

[Stefan Meiers]

Hallo Leute, <br>
verwende folgende Routine des DEC von Hagen <br>
<br>
with TCipher_Blowfish.Create('Password', nil) do<br>
try<br>
Edit1.text := DecodeString(Edit1.text);<br>
finally<br>
Free;<br>
end;<br>
<br>

Bei Create geb ich jetzt 'Passwort', nil an. <br>
Was bedeuted dieses nil? <br>
Weis nur das es TProtection ist... <br>
<br>
Ich hab doch ne Verschlüsselung aber welche (z.B. 256 Bit??)<br>

[Hagen Reddmann]

TCipher_Blowfish.BufSize = 8 Bytes, Blowfish ist also eine 8 Byte Blockverschlüsselung<br>
TCipher_Blowfish.MaxKeySize = 56 Bytes, Blowfish kann also bis zu 448 Bit lange Schlüssel nutzten, deren Schlüsselraum ist demzufolge 2^446 (eg. Kombinatinen aller Schlüssel)<br>
Mit .Create('passwort', nil) bzw. .InitKey('Passwort', nil) wird das übergebenen Passwort in ein SessionKey umgewandelt bevor der eigentlich Cipher mit .Init() initialisiert wird. Dieser Sessionkey wird mit einer Hashfunction erzeugt. Dadurch ist das Passwort, falls der Cipher geknackt wurde, trotzdem noch sicher. Zusätzlich verbessert sich die Entropie des Keys dadurch. Standardmäßig wird THash_RipeMD320 als KDF benutzt (KDF=Key Derivation Function). Damit wird dem Blowfish also IMMER ein 320 Bit Key benutzt. Die Verschlüsselung in Deinem Beispiel IST 320 Bit. ALLEDINGS sagt dies NICHTS über die Sicherheit aus. Sollte der User als Passwort "a" benutzen dann ist die Tatsächliche Schlüssellänge nur 2^8 = 256 mögliche Schlüssel müsste ein Angreifer durchprobieren um GARANTIERT dieses Passwort zu ermitteln. Sollte für den Angreifer der benutzte Algo. unbekannt sein und er versucht eine verschl. Message zu knacken dann und nur dann beträgt der Aufwand des Knackens die tatsächlichen 2^320 Möglichkeiten.<br>

Im .Create() bzw. mithilfe der porperty .Protection kann ein weiterer Cipher oder Hash oder Random mit diesem Cipher "verlinkt" werden. Ein Aufruf von Cipher.CodeFile() usw. würde dann alle Objecte dieser Kette ansprechen und somit die Datei multiple verschlüsseln.<br>
Dieses Feature wird aber in Zukunft (bzw. ist jetzt schon) wieder rausgenommen, da man "theoretisch nachweisen" konnte das in jedem Zenario eine Multiple Verschlüsselung als weniger sicher eingestufft werden MUSS. Konkret: multiple Verschlüsselungen ist durchaus sicherer, es gibt aber keinen Beweis dafür. Im gegensatz dazu gibt es aber Beweise dafür das falls EIN cipher schlecht ist dann auch die multiple Verschlüsselung die starken Cipher schwächt. Sollte diese weak Cipher absolut UNSICHER sein muß man nun annehmen das auch die Sicherheit der starken Cipher einer multiplen Verschlüsselnen auf NULL sinkt.<br>

Zusätzlich wird die neue Version somit nicht nur einfacher und sicherer sondern auch wesentlich resourcen schonender.<br>

Gruß Hage

[Hagen Reddmann]

Um diese multpile Verschl. nochmal einfacher zu erkären.<br>
Zwei Cipher verschlüsseln nacheinander eine Message. Es ist nun sehr einfach nachweisbar das der eine Cipher die inverse Funktion hat wie der andere Cipher. D.h. Cipher A führt die umgekehrte Operation wie Cipher B durch. Eine multiple Verschl. kann also mit Cipher A verschlüsseln und Cipher B gleich wieder entschlüsseln. Damit wäre natürlich die Message absolut unsicher, da Input = Output. Nun es ist logisch und auch mathematisch rel. einfach nachweisbar wie hoch die wahrscheinlichkeit ist das zwei Cipher bei gegebener Blocklänge sich einander aufheben. Diese Wahrscheinlichkeit ist NUR 100% bei sich vollständig invertierenden Ciphern, aber IMMER > 0% bei beliebigen Ciphern. Eine sichere multiple Verschlüsselung muß nun nachweisen das dieser Prozentsatz absolut sicher 0% beträgt, bzw. so gering ist das das Gesamtprodukt der Verschlüsselungsstärken beider Cipher nicht geringer ist als die Stärke jeden einzelnen Ciphers. Wird aber nun im laufe der zeit EINER der beiden Cipher gebrochen, so fällt 50% der Gesammtsicherheit weg und die restlichen 50% des anderen ciphers wird zur Hälte geschwächt. D.h. die Gesammtstärke beträgt nun noch 25%. Damit wäre eine halb gebrochene 2 fach Verschlüsslung nur noch halb so stark wie eine 1 fach Verschlüsselung mit dem nichtgeknackten Cipher.

So, ich hoffe jetzt ist es klar warum ich die multiple Verschl. wieder aus dem DEC entfernt habe.

Gruß hage

[Stefan Meiers]

Mensch Hagen, <br>
vielen Dank für deine umfangreiche Erklärung<br>
<br>
Hat mich schon beeindruckt!!! <br>
<br>
Weis jetzt bescheid -- vielen Dank. <br&gt