Hallo,

Es geht eigentlich nicht wirklichs um erkennen sondern darum zu erkennen ob eine datei ordnungsgemäß entschlüsselt wurde. Ich hab mir gedacht ich Hash die Datei im Unverschlüsselten Modus, verschlüssle die Datei dann und häng den Hash an die datei dran.

Meine Frage dazu ist, ist das Risiko das die datei leichter entschlüsselt werden kann groß oder eher nicht? Gibts andere Wege soetwas zu prüfen?

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

elundril hat folgendes geschrieben:

Meine Frage dazu ist, ist das Risiko das die datei leichter entschlüsselt werden kann groß oder eher nicht? Gibts andere Wege soetwas zu prüfen?

Hashe die Daten und hänge den Hash an die Daten an, dann verschlüssel das ganze in einem.

Wenn Du Daten verschlüsselst, dannstelle möglichst zufällige Daten (z.B. den Hash) diesen voran, um die Vorteile von Feedback-basierten Chiffren zu nutzen. Dadurch dass zufällige Daten am Anfang erscheinen, die durch den Feedback-Modus (gibt dazu mehrere Möglichkeiten) mit in den Chiffre-Strom einfließen, werden Known-Plaintext-Angriffe erschwert.

Machen z.B. GnuPG und andere bekannte Verschlüsslungsprogramme beim Verschlüsseln von Daten so: Die Datei wird komprimiert abgelegt UND davor ein zufälliger Datenblock geschrieben. Damit ist für einen Angreifer so gut wie keine Redundanz vorhanden.

Jede bekannte Klartext-Stelle kann zur Ermittlung des Schlüssels missbraucht werden. Deshalb ist etwas i.A. umso sicherer, je weniger Redundanz in den entschlüsselten Daten steckt - IMMER unter der Voraussetzung, es ist nachprüfbar UND auch bei Bekanntsein des Verfahrens sind keine Schwachstellen ausnutzbar.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

Jede bekannte Klartext-Stelle kann zur Ermittlung des Schlüssels missbraucht werden.

Das bedeutet, daß das eigentliche Verfahren sehr unsicher ist. Moderne gute Verfahren sind gegen solche "Known plaintext"-Attacken en.wikipedia.org/wik...own-plaintext_attack
geschützt. Daß das Umfeld bzw. Protokoll fehlerhaft sein kann, ist eine andere Sache.

BenBE hat folgendes geschrieben:

Deshalb ist etwas i.A. umso sicherer, je weniger Redundanz in den entschlüsselten Daten steckt

Das ist ja wohl in der Regel nicht zu erreichen, es sei denn Du meinst die vorgeschalte Komprimierung. Aber selbst das ist eigentlich nicht gut, denn dann erfährt ein Angreifer etwas über die Redundanz des Klartextes, die er ohne Kompression nicht erhielte.

Gruß Gammatester

Gammatester hat folgendes geschrieben:

BenBE hat folgendes geschrieben: Jede bekannte Klartext-Stelle kann zur Ermittlung des Schlüssels missbraucht werden. Das bedeutet, daß das eigentliche Verfahren sehr unsicher ist. Moderne gute Verfahren sind gegen solche "Known plaintext"-Attacken en.wikipedia.org/wik...own-plaintext_attack geschützt. Daß das Umfeld bzw. Protokoll fehlerhaft sein kann, ist eine andere Sache.

Ich weiß. Ein Beispiel dafür ist AES, wobei selbst dort Komprimierung eingesetzt wird, um das nötige Schlüsselmaterial zu reduzieren. Zufallszahlen auf einem deterministischen Rechner SIND teuer!

Gammatester hat folgendes geschrieben:

BenBE hat folgendes geschrieben: Deshalb ist etwas i.A. umso sicherer, je weniger Redundanz in den entschlüsselten Daten steckt Das ist ja wohl in der Regel nicht zu erreichen, es sei denn Du meinst die vorgeschalte Komprimierung. Aber selbst das ist eigentlich nicht gut, denn dann erfährt ein Angreifer etwas über die Redundanz des Klartextes, die er ohne Kompression nicht erhielte.

Dazu müsste er den Plaintext ja sowieso kennen, bzw. dessen größe. Und ja, ich meine die vorgeschaltete Komprimierung in besagten Programmen. Und ich denke mal nicht, dass diese dass nutzen würden, wenn es nicht zumindest die Sicherheit verbessert.

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

Wenn Du Daten verschlüsselst, dannstelle möglichst zufällige Daten (z.B. den Hash) diesen voran, um die Vorteile von Feedback-basierten Chiffren zu nutzen. Dadurch dass zufällige Daten am Anfang erscheinen, die durch den Feedback-Modus (gibt dazu mehrere Möglichkeiten) mit in den Chiffre-Strom einfließen, werden Known-Plaintext-Angriffe erschwert.

Ich versteh irgendwie nicht ganz was du meinst.

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

Nehmen wir an, Alice surft im Internet über eine verschlüsselte Verbindung, Bob ist Server-Betreiber und das Protokoll sieht so aus:

A: eigene Key-ID
B: Key-Accept-Message (Acknowledgement)
A: (verschlüsselt) HTTP-Anfrage (also so wie auf Port 80 der Browser)
B: (verschlüsselt) angesurfte Website (nomale HTTP-Antwort laut RFC)
B: Beendet Verbindung wenn Übertragung fertig

und nehmen wir weiter an, der verwendete Chiffre nutzt den CBC-Modus (Chiffre Block Chaining), dann könnte Malice auf einfache Art und Weise Herausfinden, was Bob gesendet hat, indem er Beispiel-Codeblöcke "GET ", "POST", "PUT ", "PROPFIND", "PROPGET ", ... mit Alice's Key verschlüsselt und dann auf Äquivalenz prüft.

Wenn Bob jetzt mit Alice zusätzlich ausmacht, dass das erste übertragene Kilobyte zufälliger Datenmüll ist, kann Malice zwar immer noch probieren dieses Kilobyte zu erraten, er muss aber, bevor er beurteilen kann, um was für eine Anfrage es sich bei Bob gehandelt hat, eine wesentlich höhere Schranke überwinden (das gesamte zufällige Kilobyte erraten).

Nutzen Alice und Bob zudem im verschlüsselten Teil ihrer Kommunikation Komprimierung kann der Teil in dem sich entscheided, um was für eine Anfrage es sich handelt zudem noch verschieben. Malice müsste in diesem Fall nicht nur die zufälligen Datenbytes erraten, sondern auch noch die komprimierten Anfragen-Bytes korrekt erkennen, um einschätzen zu können, was für eine Anfrage gesendet wurde. Um aber zu validieren, ob er die zufälligen Daten richtig hat, muss er diesen Block IMMER vollständig erraten UND hat zudem die Komprimierung zusätzlich zu umgehen.

Ich weiß, das gewählte Protokoll ist bewusst unsicher gewählt und wenn SSL in Wirklichkeit so arbeiten würde, würde es keine nutzen, aber ich denk mal, für die Demonstration warum ohne zufällige Daten ein Known-Plaintext-Angriff einfach möglich ist, sollte dieses Protokoll vollkommen reichen ...

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

Bei deiner Aussage gehst du aber von einem öffentlichen Schlüssel aus und dieser Angriff ist nur bei einem sehr naiven RSA möglich!

Ich denke aber mal, dass sich elundril's Frage eher auf symmetrische Algorithmen beziehen, welche grundsätzlich zur Datenverschlüsselung eingesetzt werden. Moderne Verschlüsselungsverfahren haben dabei keine bekannten schwachstellen für Known-Plaintext Angriffe.

Um zur Integritätssicherung zurück zu kommen: Diese ist immer sinnvoll von dem Original zu erstellen und mit zu verschlüsseln! Dadurch hat man die Sicherheit, dass bei einer falschen Entschlüsselung sogar der Hash falsch sein wird, sodass der Fehler auf jeden Fall erkannt werden wird und eine Manipulation ist nicht Möglich! Bei großen Datenmengen sollte man grundsätzlich den CBC-Modus verwenden, sodass doppelte Dateifragmente nicht als solche identifiziert werden können.
Ein Known-Plaintext Angriff ist aber grundsätzlich außerhalb alles erdenkbaren, weil selbst ein komplett bekannter Klartextblock benötigt einen Bruteforce Angriff!

Vom Hash kann man grundsätzlich keine Rückschlüsse auf die Datei machen, sodass selbst deine Variante möglich wäre, jedoch gibt es bessere und diese sollte man dann auch nutzen!

das heißt ich sollte das ganze ungefähr so ablaufen lassen:

1.) Hash der Datei bilden (Ist MD5 der Sicherste. SHA-1 und GOST sind es nicht.)
2.) Hash der Datei vorne Ranstellen
3.) Irgendwelchen Datenmüll in bestimmter Länge vorne und hinten dazugeben
4.) Mit AES verschlüsseln (Ist doch der sicherste symetrische Algo, oder??)
( 5.) Zippen??? )

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

elundril hat folgendes geschrieben:

4.) Mit AES verschlüsseln (Ist doch der sicherste symetrische Algo, oder??) ( 5.) Zippen??? )

Wenn komprimieren, dann vor dem Verschlüsseln.

elundril hat folgendes geschrieben:

1.) Hash der Datei bilden (Ist MD5 der Sicherste. SHA-1 und GOST sind es nicht.) 2.) Hash der Datei vorne Ranstellen 3.) Irgendwelchen Datenmüll in bestimmter Länge vorne und hinten dazugeben 4.) Mit AES verschlüsseln (Ist doch der sicherste symetrische Algo, oder??) ( 5.) Zippen??? )

SHA1 ist sicherer als MD5, zumindest gegen Kollisionen. Nur weil in dem Heise-Artikel steht, dass Fortschritte beim Finden von SHA1-Kollisionen gemacht wurden, heißt das nicht, dass MD5 deswegen sicherer ist. Im Gegenteil.
Meiner Meinung nach sollte es völlig genügen wenn du den SHA1-Hash der Datei vorn oder hinten an die Datei anhängst und das ganze verschlüsselst.
Als sicherster symmetrischer Algorithmus wird übrigens Serpent angenommen:

Zitat:

Serpent scheint eine sicherere Architektur als Rijndael zu haben, war aber der langsamste der Finalisten. MARS, Twofish und Serpent wurden als hoch-sicher eingestuft, während Rijndael und RC6 "nur" als hinreichend-sicher eingestuft wurden.

auch in der gefahr jetzt OT zu geraten: Warum verwendet man im Internet (wie bei Passwörtern in zb: Foren) dann MD-5 wenn es mittlerweile bessere gibt?

lg elundril

This Signature-Space is intentionally left blank.
Bei Beschwerden, bitte den Beschwerdebutton (gekennzeichnet mit PN) verwenden.

elundril hat folgendes geschrieben:

das heißt ich sollte das ganze ungefähr so ablaufen lassen: 1.) Hash der Datei bilden (Ist MD5 der Sicherste. SHA-1 und GOST sind es nicht.) 2.) Hash der Datei vorne Ranstellen 3.) Irgendwelchen Datenmüll in bestimmter Länge vorne und hinten dazugeben 4.) Mit AES verschlüsseln (Ist doch der sicherste symetrische Algo, oder??) ( 5.) Zippen??? ) lg elundril

Das ganze sieht nach einem ziemlichen Adhoc-Lösungsversuch aus, über die (Un-)Sicherheit von MD5 haben schon andere geschrieben.

Wenn Du Verifikation von Authentizität haben möchtest, kannst Du z.B. den dafür vorgesehenen EAX-Modus verwenden, siehe en.wikipedia.org/wiki/EAX_mode.

Sichere Schlüssel und IVs sollten aus Passphrasen und "Salz" berechnet werden z.B. gemäß Standard PKCS#5 mit oder mit anderen KDF-Funktionen.

Gruß Gammatester

Sowohl MD5 als auch SHA1 gelten unter Kryptographen als gebrochen. Verwende stattdessen SHA256 oder SHA512 (für letztere ist mir aber leider bisher keine Delphi-Implementation bekannt). Ferner sollte man reine Hashes wenn man kann etwas vermeiden. Wie wär's z.B. den Initialisierungsvektor deines Chiffres mitzuhashen? Wichtig ist aber nur, dass Du beide Male die gleichen Daten hasht.

@Zippen: Komprimierung wird sinnvoller Weise IMMER vor dem Verschlüsseln gemacht:
1. Durch die Verschlüsslung bleibt nahezu keine Redundanz übrig (das Chiffrat soll ja Zufällig aussehen)
2. Eine nachträglich komprimierte Datei knn von einem Angreifer Problemlos entpackt werden, womit dieser Schritt einfach rückgängig gemacht werden kann.

Bzgl. Verschlüsslung: Serpent-Twofisch-Kaskade sollte da grad ausreichen. Ansonsten einfach noch weiter kaskadieren. Macht TrueCrypt ja auch - also für die GANZ paranoiden unter uns

@OT: Weil PHP die MD5-Funktion als eine der ersten Hash-Funktionen Built-in hatte und das meiste, was es für PHP an Software gab, diesen im großen Stil eingesetzt hat. Jegliche Derivate natürlich dann auch, ... Bin inzwischen übrigens zu Multi-Salted-SHA512 bzw. APR1-Hashes (Bei Auth gegen Apache, ist ne MD5-Kaskade) übergegangen. Bedarf allerdings einer Extension (Suhosin), die man aber eh installiert haben sollte, weil damit PHP an sich etwas "gereinigt" wird ...

@Gammatester: Gibt's den Standard auch in Verständlich. Weil irgendwie blick ich die ganzen Krypto-Standards immer nicht ohne Annotations

Anyone who is capable of being elected president should on no account be allowed to do the job.
Ich code EdgeMonkey - In dubio pro Setting.

BenBE hat folgendes geschrieben:

@Gammatester: Gibt's den Standard auch in Verständlich. Weil irgendwie blick ich die ganzen Krypto-Standards immer nicht ohne Annotations

Ich beziehe mich hier eigentlich nur auf die pbkdf2-Funktion und die ist eigentlich ganz verständlich dargestellt (Eingabe: Passphrase, Salz, Iterationsanzahl; Ausgabe: beliebig langes Schlüsselmaterial).

Bischen mehr Info bei en.wikipedia.org/wiki/PBKDF2, Quellcode z.B. in meinem CRC/Hash-Archiv, Unit KDF (home.netsurf.de/wolf...ardt/crchash_de.html)

Gammatester

Der EAX ist in dem Paper, was Wiki als Link drin hat, ganz gut erklärt auch mit Bild
The EAX Mode of Operation

Nun geht es in dem Thema langsam um Implementierung und welche Sicherheitsdienste verlangt werden! Im ersten Post wurde nur Vertraulichkeit und Integrität - und das an sich nur als Fehlererkennung - erwähnt. Der EAX Mode geht noch etwas weiter!

Daher ist an sich für weitere Spekulationen zu sinnvollen Implementierungen von Notwenidigkeit das Projekt zu kennen, um zu entscheiden, was man an Primitiven wie einsetzen kann!