Dateien verschlüsseln

[Torsten Grundke]

Hallo,

ich speichere verschlüsselte Bilder(JPEG) in einer DB. Dabei gehe ich momentan so vor:

- Passwort erfassen und daraus einen Hashwert ermitteln<br>
- das Passwort selber wird nicht gespeichert und auch nicht auf Korrektheit geprüft (falls es falsch ist bekommt man beim entschlüsseln halt nur Datenmüll zurück)<br>
- der Hashwert wird als Schlüssel für einen Cipher(IDEA) verwendet<br>
- die Datei wird gepackt und danach mit dem Cipher verschüsselt in der DB abgelegt<br>

Weil alle Dateien mit dem gleichen Schlüssel verschlüsselt werden besteht meiner derzeitigen Kenntnis nach die Möglichkeit der Kryptoanalyse, da sowohl das JPEG-Format wie auch die gepackten Dateien ein bestimmtes Header-Format aufweisen (vermute ich mal).

Als Lösungsansatz sehe ich 2 Möglichkeiten:

- vor das eigentliche Passwort wird eine Zufallssequenz eingefügt und separat in der DB gespeichert (verschlüsseln notwendig?)<br>
- aus der Kombination Zufallssequenz + Passwort wird ein Hashwert ermittelt und die Datei damit verschlüsselt<br>
- im Endeffekt wird erreicht das jede Datei mit einem anderen Schlüssel verschlüsselt wird<br>

oder

- der zu verschlüsselnden Datei wird ein zusätzlicher Datenbereich mit Daten aus einem Zufallsgenerator vorangestellt und danach verschlüsselt

Ich möchte jetzt gern wissen ob ich in die richtige Richtung denke und was ich zusätzlich noch beachten sollte.

Tschüß

Torsten

[Hagen Reddmann]

Richtig. Das eine nennt man Salt, eg. H(Salt || Passwort) = SessionKey das andere nennte man Zufallsexpansion der Nachricht.<br>

Nun ein bißchen Logik.<br>

Wenn H(Passwort) = Sessionkey = Sicherheitsfaktor 1 ist dann ist H(Salt || Passwort) = Sessionkey + sichtbarer Salt = Sicherheitsfaktor 1. Mit anderen Worten "nichts gewonnen" da wir davon ausgehen müssen das dem Angreifer der Salt zur Verfügung steht, und die Transformierung per H() sich im Sicherheitsfaktor NICHT verändert.<br>
Man möge argumentieren das sich ja dann ein zufälliger und immer anderer Wert für den SessionKey ergibt. Das ist richtig, aber das eigentliche Geheimniss = Passwort ist trotzdem gleich geblieben.<br>

Nun, der zweite Fall: Zufällige Messageexpansion. Da wir annehmen das unser Cipher mit einem Feadback-Modus arbeitet würde eine Messageexpansion am Anfang der messages mit > 128 Bit einen Lawineneffekt über die komplette Message produzieren, da ja beim Feadbackmodus die Verschlüsselung des nächsten Blockes von der Verschlüsselung des Vorgängerblockes (Daten und CipherText) abhängt.<br>
Um's kurz zu machen: ich preferiere diesen Weg gegenüber einem InitVector. Zusätzlich sollte noch der Salt ins Passwort eingerechnet werden da damit zwar nicht die Sicherheit der JPEG's erhöht wird aber die Sicherheit des benutzten Passwortes.<br>

Alles in Allem sind obige Aspekte aber immer noch nicht Grund genug das Passwort NICHT regelmäßig zu wechseln oder ein viel zu einfaches und zu kurzes Passwort zu nutzen.<br>

Gruß Hagen

PS: achso hier noch ein guter Trick. Du berechnest H(Salt || Passwort) = SessionKey und [Salt, CipherText] = C(SessionKey || PlainText).<br>
D.h. ein 128 Bit zufälliger Salt wird mit dem Passwort verknüft, ein SessionKey berechnet, dieser wird vor die Message gehängt und beides verschlüsselt.<br>

Da Salt = Zufall so H(Salt || Passwort) = Zufall. Damit kann der Sessionkey auch als zufällige Messageexpansion benutzt werden, wobei hier sogar dies sicherer IST als nur Zufall dafür zu nehmen. Angenommen dem Attacker gelingt es den Zufallsgenarator zu knacken, dann wäre aber H(Zufall || Passwort) trotzdem sicher da wir annehmen H() = Hashfunktion IST sicher und Passwort ist unbekannt. Damit ist C(SessionKey || PlainText) sicherer als C(Zufall || PlainText).<br>

Aber der schöne Nebeneffekt ist das wir nun nur die ersten 128 Bit = SessionKey Länge, entschlüsseln müssen um feststellen zu können ob unserer Entschlüsselung mit dem richtigen Key arbeitet.<br>
Um aber korrekt entschlüsseln zu können um an den verschlüsselten SessionKey zu gelangen muß erstmal der richtige SessionKey als Schlüssel benutzt werden. Heist es ist sicher.<bR&gt

[Torsten Grundke]

Hallo Hagen,

erst einmal Danke. Die Dateiexpansion wollte ich mir eigentlich sparen, aber letzlich ist der Aufwand dafür ja nicht allzu groß.

Wenn man unterstellt das das Passwort sicher ist, sind dann immer noch Ansatzpunkte für eine Kryptoanalyse (z.B. Eigenheiten im JPEG-Dateiformat) vorhanden?

Tschüß

Torste

[Hagen Reddmann]

Durch die Zufällige Expandierung und die <b>vorherige</b> komprimierung ändert sich die komplette Entropie der Message. Mit einem Cipher im Feadbackmodus wie cmCTS gibt es keinerlei Anhaltspunkte mehr. Anders ausgedrückt: für den Angreifer könnte es JEDE Message sein, bzw. selbst wenn er die verschl. JPEG als unverschl. vorliegen hätte könnte er trotzdem nicht den Cipher knacken, im fehlen einfach die ersten 128 Bit=H(Zufall + Password) der Message, die aber die Verschl. durch den Cipher auf Grund dessen Lawineneffekt im Feadbackmodus komplett beeinflussen. Durch die Nutzung von H() = Hashfunktion hat er noch nicht mal die Chance den Zufallsgenerator der "Zufall" produziert hat anzugreifen, selbst wenn dieser sehr schlechten und berechnenbaren Zufall erzeugte. Was natürlich vermieden werden sollte, also zumindestens mal Randomize() aufrufen, oder ganz auf Random() verzichten und die PRNG's aus dem DEC benutzen.<br>
Der Output sollte wie <b>nicht signifikant komprimierbarerer</b> Zufallstrom erscheinen.<br>

Da auch das Passwort mit dem Salt versehen wurde und es > 28 Zeichenlang sein sollte und der Cipher ein Cipher mit >= 128 Bit ist, meine ich <b>das knackt Dir keiner so schnell in den nächsten 100 Jahren </b>.

Jetzt stellen sich dir die praktischen Probleme:
<li>was machst'e wenn der User sein Passwort vergessen hat ?
<li>was machst'e wenn mehrere User das Bild laden möchten ?

Hage

[Hagen Reddmann]

Übrigens, Torsten, fällt's mir jetzt erst auf<br>
<b>Was sind denn das für brisante JPEG's ???</b>
Du weist das bei einer polizeilichen Beschlagnahme durch richterlichen Beschluß Du gezwungen bist das Passwort preiszugeben. Solltest Du das nicht können/wollen wird Dir der Tatverdacht unterstellt und zusätzlich noch Behinderung der Staatsmacht vorgeworfen.<br>
Zwei Auswege:
<li>1. Steganographie, die gute Sorte ist NICHT entdeckbar !
<li>2. es gibt eine Form der Public Key Verschlüsselung, bzw. fast alle PK's sind dazu in der Lage, mit der man ein NICHT Geheimniss verschlüsselt und das WAHRE Gehemniss darin einbettet. Wird der "falsche" bzw. "halbe" Key preisgegeben dann wird NUR das NICHT-geheimniss also unwichtige Message entschlüsselt (sollte NICHT ZU UNWICHTIG sein, die Polizei ist nicht doof). Erst mit dem richtigen Schlüssel wird die wichtige sublimitare Message entschlüsselt.<br>

Der letztere Fall ist sehr sehr raffiniert, da es Steganograhie in einer bestehenden Verschlüsselung darstellt. Die meisten Public Key Verfahren haben solche versteckten Kanäle. Damit ist es durchaus möglich z.B. im PGP in einer Digitalen Unterschrifft zusätzlich Nachrichten abzulegen. Die eine Seite (PGP Programmierer oder das TrustCenter z.B. Staat der diese Ausweise ausgibt) könnte dort Infos. ablegen die es erlauben den Private Key zu knacken, die andere Seite irgendwelche geheimen Nachrichten.<br>

Im Falle der Entdeckung wird einfach entschlüsselt und die rel. unwichtige, NICHT belasstende Nachricht gezeigt. KEINER kann beweisen das da noch eine Message versteckt ist, es sei denn er hat das nötige Wissen und Algo und Passwort um dies Message zu entschl.<br>

gruß hage

[Torsten Grundke]

Hallo Hagen,

da ich auf absehbare Zeit der alleinige User bin müßte ich meinen Allerwertesten anknappern oder auf gut deutsch "mir in den Arsch beissen".

Ansonsten sei nicht so neugierig!

Tschüß

Torste

[Hagen Reddmann]

<I>Ansonsten sei nicht so neugierig!</i><br>
Falls es par gute Schnappschüsse Deiner Freundin sind will ich doch hoffen das du sie hier im Forum uploadest !!<br>
Thema: Win32-API <i>Beispielanwendung für einen Windows-Hook mit JPEG Screenshots</i>

Gruß Hage

[Torsten Grundke]

Hallo Hagen,

ich mach doch nicht's strafrechtlich Relevantes. Also da muß ich mich doch besorgt fragen was Du von mir denkst. :-)

Und wenn ich es denn offenlegen müßte, dann könnte ich damit auch problemlos leben. Sind ja nur ein paar Private Bilder.

Unabhängig von der sicheren Verschlüsselung bleibt ja immer noch das Restrisiko Passwort. Und dafür gibt es ja mehr als genug Möglichkeiten zum Ausspionieren, damit kann ich aber leben.

Die Info's zu den PK hören sich ja sehr interessant an (ich habe dafür zwar derzeit keine Verwendung aber Weiterbildung schadet nie). Damit hätte ich wenigstens wieder einen Grund das mittlerweile schon stark angestaubte Buch "angewandte Kryptographie" mir noch einmal zu Gemüte zu führen (vor 5 Jahren habe ich mich schon einmal mit PK's beschäftigt aber mittlerweile ist davon nicht mehr viel übrig geblieben).

Tschüß

Torste

[Torsten Grundke]

Hallo Hagen,

irgendwie bin ich zu langsam.

Von Windows-Hook's lasse ich soweit es geht die Finger weg. Mein letzter hat zwar grundsätzlich gut funktioniert, allerdings hat sich mein Programm dann so ca. 1 mal die Woche von selbst verabschiedet (ohne Fehlermeldung). Der Fehler war nicht nachvollziehbar. Nur das Entfernen des Hook hat nachhaltigen Erfolg gebracht.

Also mit dem Upload wird das dann wohl nix werden.

Tschau

Torste

[Hagen Reddmann]

Die gleichen Erfahrungen mit Hook's hab ich auch gemacht. Selbst wenn Du alles berücksichtigst und so sicher wie möglich bastelst, und du kannst mir glauben ich habe wirklich alles versucht (bis hin das ich mich auf MS C++ hinabgelassen habe). Es funktioniert einfach nicht. Unter Win95/98 z.B. wird mit solchen Hooks, egal welcher Typ, auf kurz oder lang irgendwann der Explorer sammt Shell abkacken.
Unter Win2000 gehst teilweise dann soweit das selbst der taskmanager blockiert ist.<br>

Beim Upload gings mir natürlich nur um die JPEG "ScreenShots" )

<i>. Also da muß ich mich doch besorgt fragen was Du von mir denkst. :-) </i>
Geht zwar ins philosophische, aber ich traue jedem das zu was ich mir vorstellen kann bzw. mir im extremsten Fall selber zutraue, und das ist <b>ALLES</b> !<br>

Im HAC oder Applied findest du über diese Sublimitaren Messages fast garnichts, es wird nur mal so erwähnt. Es gibt im WEB par neuere PostScripts die mehr umschreiben, meistens sind es irgendwelche Kryptoanalyseberichte.<br>
Die Sache an sich ist eigentlich nicht so schwierig.<br>
Als erste Regel gilt: Alles was Zufall ist ist gut für den Kryptographen und schlecht für den Kryptoanalysten. Und alles was zufällig aussieht ist niemals zufällig !<br>
D.h. wenn in einem Kryptoverfahren Zufall benutzt wird um es sicher zu machen, dann stellt dieser Zufall eine Möglichkeit um als versteckter Informations-Kanal zu dienen dar.<br>
Im Falle von digitalen Signaturen wird der Hash über das Dokument im PK Verfahren mit Zufallsdaten expandiert (auf die Länge des public Modulus). Im Falle einer RSA Signatur, also einer Signatur mit Messagerecovery wird bei der Überprüfung der Signatur dieses Zufallspadding wieder sichtbar. Schwups, und schon haben wir unseren versteckten Kanal, denn was spricht dagegen diesen Zufallspad mit zusätzlichen Daten zu versehen so daß es nach Zufall aussieht es aber tatsächlich keiner ist.<br>
Besonders prädestiniert für solche Kanäle ist z.B. das in den USA weitakzeptierte, staatlich anerkannte und vom NSA entwickelte DSA Verfahren (Digital Signature Algorithm). Es sollen wohl mittlerweil über 20 verschiedene Mögichkeiten geben im DSA solche Kanäle einzurichten.<br>

Hagen
&#10

[Robert Marquardt]

Ich habe einen (in C geschriebenen) Shell Hook laufen und keine Probleme.<br>
Man muss nur wissen das die Taskleiste selbst Hooks verwendet und dabei unsauber programmiert ist

[Hagen Reddmann]

Korrekt, trotzdem ist es mir zu unsicher