Mit einem einzigen Rechner bekommt man meines wissens nach auch einen 40 Bit Key nicht so schnell ge brutforced...
Das ist auch logisch, aber wie schon oben gesagt, es geht hier nunmal um ein Dateiarchiv. Da wird nicht der Key geknackt, sondern das Passwort. Das ist der feine Unterschied, daher ist die Verschlüsselungsstufe hier unbedeutend.
Du kannst auch den Key cracken und dann das Archiv manuell entschlüsseln (Eigenbausoftware), wenn Du den Algorithmus hast (ich nehme an der ist open-source). Und alle ZIP-Programme verwenden meines Wissens nach zur Verschlüsselung die "Huffman-Encryption". Aber widersprech' mir ruhig wieder. Ich bin das gewohnt.
Mit einem einzigen Rechner bekommt man meines wissens nach auch einen 40 Bit Key nicht so schnell ge brutforced...
Das ist auch logisch, aber wie schon oben gesagt, es geht hier nunmal um ein Dateiarchiv. Da wird nicht der Key geknackt, sondern das Passwort. Das ist der feine Unterschied, daher ist die Verschlüsselungsstufe hier unbedeutend.
Stimmt, da hast du recht...wenn es aber sagen wir ein 8 zeichen langes PW ist, möglicherweise noch mit zahlen UND buchstaben...dann kannste das vergessen, dann hast du alle Buchstaben, das sind schonmal 26, dann möglicherweise noch Casesensitive, dann sinds nochmal 26 plus ziffern, das sind weitere 10, dann haben wir 62^8...das wären dann 218340105584896 mögliche kombinationen... (ich hoffe ich habe das richtig ausgerechnet )
Du kannst auch den Key cracken und dann das Archiv manuell entschlüsseln (Eigenbausoftware), wenn Du den Algorithmus hast (ich nehme an der ist open-source). Und alle ZIP-Programme verwenden meines Wissens nach zur Verschlüsselung die "Huffman-Encryption". Aber widersprech' mir ruhig wieder. Ich bin das gewohnt.
Ok - eigentlich ist jeder moderne Verschlüsselungsalgo sozusagen Open-Source - ist auch Absicht, anders kann man die Sicherheit einens Algos nicht effektiv testen. Nur aus keinem aktuellen Algo lässt sich der Key reproduzieren (war vor 30 Jahren noch anders), sonst wäre z.B. PGP völlig für die Katz.
Aber wie schon gesagt - bei Dateiarchiven zählt halt nicht der Key bzw. die Verschlüsselungsrate, sondern das nur Passwort. Genau deswegen ist hier auch eines der letzten sinnvollen Einsatzgebiete für BruteForce, denn das Passwort bestimmt die Sicherheit des Archivs, die Verschlüsselungshöhe ab 40Bit kaum noch, weil es ab da (und praktisch schon viel eher) uninteressant wird den Key zu ermitteln.
(siehe Pirkes Beispiel)
Stimmt, da hast du recht...wenn es aber sagen wir ein 8 zeichen langes PW ist, möglicherweise noch mit zahlen UND buchstaben...dann kannste das vergessen, dann hast du alle Buchstaben, das sind schonmal 26, dann möglicherweise noch Casesensitive, dann sinds nochmal 26 plus ziffern, das sind weitere 10, dann haben wir 62^8...das wären dann 218340105584896 mögliche kombinationen... (ich hoffe ich habe das richtig ausgerechnet )
Genau so ist es - Daher: Bei einer brauchbaren Verschlüsselung (z.B. 128Bit) UND einem guten Passwort (z.B. 20 stellig mit Ausnutzung der kompletten ASCII Tabelle) gibt es für einen Privatmenschen praktisch kein Mittel an die Daten zu kommen.
Ok - eigentlich ist jeder moderne Verschlüsselungsalgo sozusagen Open-Source - ist auch Absicht, anders kann man die Sicherheit einens Algos nicht effektiv testen. Nur aus keinem aktuellen Algo lässt sich der Key reproduzieren (war vor 30 Jahren noch anders), sonst wäre z.B. PGP völlig für die Katz.
Toll! Was mache ich denn wenn ich verschlüsselt Daten austauschen möchte. Ich gebe dem Empfänger meinen Key oder der Empfänger gibt mir seinen Key. Den muss ich erstmal haben, mit dem verschlüssele ich dann. Während der Übertragung des Keys kann man mithören und damit den gesamten verschlüsselten Datenverkehr abhören. Das lässt sich kaum vermeiden, so ist es nunmal. Und das ist auch bei meiner Verschlüsselung nicht anders. Hast Du den Key, hast Du alles. Will man das nun vermeiden, muss man den Keyaustausch verschleiern. Genau hier setzt asymmetrische Verschlüsselung an. Per Diffie-Hellman-Verfahren ausgetauschte Schlüssel lassen sich nur schwer rekonstruieren. Das heißt wenn der Keyseed von meiner Verschlüsselung über ein solches Verfahren ausgetauscht werden würde, wäre sie sicher.
Nun aber zurück zum Dateiarchiv. So! Damit das ZIP-Programm die Daten entschlüsseln kann, benötigt es einem Schlüssel. Ich vermute mal, dass dieser in der ein oder anderen Form in der Datei zu finden ist. Dann nimmst Du diesen Schlüssel und jagst Deine Datei zusammen mit dem Schlüssel durch den Entschlüsselungsalgorithmus der Huffman-Encryption. Et voilà Deine Originaldatei. Ist in etwa das gleiche wie das Cracken von Word-Dateien. Word-Dateien verwenden einen 16-bit Key, das sind 65536 Kombinationen und daher billig. Lass einfach ne Bruteforce Attacke laufen. So lang wird's schon nich dauern. Wie gesagt, wenn Dein ZIPper noch die konservative Huffman-Encryption verwendet, dann ist's relativ einfach und dauert auch nich lange. Ich gehe davon aus, dass kein stärkerer Algo verwendet wird, denn das wäre gegen den ZIP-Standard. Also schmeiß den Bruteforcerechner an und warte einen Tag, dann hast die Daten.
Auf den ersten Teil des Postings gehe ich mal absichtlich nicht ein, ich muss wohl nicht sagen warum
Zitat:
Zitat von Qndre
Nun aber zurück zum Dateiarchiv. So! Damit das ZIP-Programm die Daten entschlüsseln kann, benötigt es einem Schlüssel. Ich vermute mal, dass dieser in der ein oder anderen Form in der Datei zu finden ist.
Ja aber verschlüsselt, du drehst dich also sinnlos im Kreis.
Zitat:
Zitat von Qndre
Dann nimmst Du diesen Schlüssel und jagst Deine Datei zusammen mit dem Schlüssel durch den Entschlüsselungsalgorithmus der Huffman-Encryption. Et voilà Deine Originaldatei. Ist in etwa das gleiche wie das Cracken von Word-Dateien. Word-Dateien verwenden einen 16-bit Key, das sind 65536 Kombinationen und daher billig. Lass einfach ne Bruteforce Attacke laufen. So lang wird's schon nich dauern. Wie gesagt, wenn Dein ZIPper noch die konservative Huffman-Encryption verwendet, dann ist's relativ einfach und dauert auch nich lange. Ich gehe davon aus, dass kein stärkerer Algo verwendet wird, denn das wäre gegen den ZIP-Standard. Also schmeiß den Bruteforcerechner an und warte einen Tag, dann hast die Daten.
BITTE VERSTEH DOCH ENDLICH, DASS BEI PASSWORTABFRAGEN UND BRUTEFORCE-ANGRIFFEN AUF SELBIGE, WEDER DIE VERSCHLÜSSELUNGSSTÄRKE NOCH DER VERWENDETE ALGO IRGENDEINE ROLLE SPIELEN!
Auch wenn das Passwort als Rohdaten in der Datei drinsteht und die "Verschlüsselung" 0 Bit beträgt, wird Bruteforce dadurch kein bisschen schneller.
BITTE VERSTEH DOCH ENDLICH, DASS BEI PASSWORTABFRAGEN UND BRUTEFORCE-ANGRIFFEN AUF SELBIGE, WEDER DIE VERSCHLÜSSELUNGSSTÄRKE NOCH DER VERWENDETE ALGO IRGENDEINE ROLLE SPIELEN!
Auch wenn das Passwort als Rohdaten in der Datei drinsteht und die "Verschlüsselung" 0 Bit beträgt, wird Bruteforce dadurch kein bisschen schneller.
Wenn das Passwort als Rohdaten drinsteht, kannst Du einen Hexeditor nehmen und es auslesen. Das brauchst Du aber garnicht. Du willst ja schließlich nicht unbedingt das Kennwort, sondern die Daten in der ZIP Datei. Nun hast Du zwei Möglichkeiten: 1. Du Bruteforce-Attackierst das Kennwort - nicht so doll - dauert ewig!
Dann gibt es noch eine andere Möglichkeit. Denn ZIP weigert sich zu entschlüsseln, wenn das Kennwort nicht stimmt. Folgliche entzippst Du die Daten "von Hand". Das machst Du, indem Du die Datei mit dem entsprechenden Schlüssel, welcher sich im Header befindet durch den Entschlüsselungsalgorithmus der Huffman-Encryption schiebst. Wenn der Schlüssel für die Datei in sich selbst verschlüsselt ist, wird vermutlich die Checksum des Kennworts zum Entschlüsseln dieses Keys vewendet. Da ZIP das Kennwort überprüfen kann liegt diese Checksum folglich auch in der Datei. Nun fütterst Du den Huffman-********* nicht mit dem Kennwort, lässt ihn die Checksum bilden und dann entschlüsseln sondern gibst ihm direkt die Checksum. Et voilà - entschlüsselt ohne Bruteforce.
) 
Linear-Darstellung
