In Artikeln über Verschlüsselung findet man häufig hübsche Farbbilder von verschlüsselten/entschlüsselten Dateien, z. B. https://blog.malwarebytes.com/wp-content/uploads/2018/02/vizStrong-900x506.png bei https://blog.malwarebytes.com/threat-analysis/2018/03/encryption-101-how-to-break-encryption/ Sowas möchte ich auch machen, z. B. um grob zu überprüfen wie es denn beim MS-Windows (Bitlocker) und Linux (LUKS) aussieht, aber welche Programme können das? Ich brauche das für einzelne Dateien, wobei unter Linux auch Datenträger (HDD, SSD, USB-Stick, Floppy, Partitionen, ...) eine Datei sind und die Größe auch mal 20 TB, oder auch mal mehr, betragen kann.
Angehängte Dateien:
-
vizStrong-900x506.png
450 KB
Erwin M. schrieb: > Sowas möchte ich auch machen, z. B. um grob zu überprüfen wie es denn > beim MS-Windows (Bitlocker) und Linux (LUKS) aussieht, aber welche > Programme können das? Jeder Hex-Editor. Du schreibst ein paar Bytes PNG-Header vor deine Datei, füllst am Ende die letzte Zeile auf, fettich. Das ist es aber nicht, was du machen möchtest, denn es ist vollkommen sinnlos. Du willst irgendetwas anderes, was du uns aber nicht verrätst. Vielleicht weißt du auch selbst nicht, was du willst, weil du null Ahnung von der Materie hast. Das einzige, was du sehen wirst, ist weitgehend weißes Rauschen, weil das per Definition das Resultat jedes effizienten Verschlüsselungsalgorithmus ist.
Was hat das bitte mit einem Hexeditor zu tun?! Was du willst, ist eine Nicht-Bild-Datei in ein Bild zu verwandeln. Nichts einfacher als das. Unter Linux kannst du zum Beispiel die Datei einfach in einen Framebuffer schreiben. Oder ein Bildbearbeitungsprogramm verwenden, das "raw data" importieren kann. Du musst dann nur ein Pixelformat und eine Zeilenbreite / Bildbreite wählen, und fertig. Das einzige, was du da aber sehen kannst, ist Rauschen. Wenn du im Bild eine ähnliche Struktur wie in der Originaldatei siehst, dann ist das eine untaugliche Blockcipher mit immer dem gleichen, kurzen Schlüssel.
Jochen schrieb: > Was hat das bitte mit einem Hexeditor zu tun?! Per Hex editor kann man wie beschrieben jede Datei so verändern, dass sie mit einem normalen Bildbetrachter als PNG decodiert werden kann.
Jochen schrieb: > Was hat das bitte mit einem Hexeditor zu tun?! Jochen nix am Hut mit Textverständnis? Kryptoexperte Schritte erklärt haben. Wenn Jochen nix verstehen, weiter Bauer sucht Frau oder ähnliches Bildungsfernsehen gucken. > Was du willst, ist eine Nicht-Bild-Datei in ein Bild zu verwandeln. > Nichts einfacher als das. Unter Linux kannst du zum Beispiel die Datei > einfach in einen Framebuffer schreiben. Und dann den Bildschirm abfotografieren und die Bilddatei von der Kamera auf den Computer ziehen. Ja so geht es auch, aber 20TB Framebuffer wird selbst auf einem 4k-Monitor eng. Dann doch lieber Hex-Editor. Aber Jochen nix verstehen, schade.
Oh, ich hatte überlesen, dass du das mit 20 TB Files bzw. HDD Images machen willst - das ergibt keinen praktishen Nutzen. Das Verfahren ist geeignet um in Dateien Bereiche zu erkennen: Textressourcen, Bilder, Code sind relativ einfach erkennbar. Auf ganzen Festplatten wirst du höchsten das Muster des FS erkennen auf gaanz alten FS wie (original) FAT vielleicht noch einzelne Dateien und bei 20 TB natürlich gar nichts mehr.
Angehängte Dateien:
-
test.png
63 KB
1 | dd if=/dev/sda1 bs=1M count=1 |python -c "import numpy as np; import matplotlib.pyplot as plt; import sys; d = sys.stdin.buffer.read(); plt.imshow(np.frombuffer(d, dtype=np.uint8).reshape(int(np.sqrt(len(d))), -1)); plt.show()" |
:
Bearbeitet durch User
Ich spreche leider kein matplot. Was sieht man da?
c r schrieb: > JJ schrieb: >> Was sieht man da? > > 1 MB Daten, farblich kodiert. Schon klar, aber wie? Hast du jedem Byte eine Farbe von 0-255 zugeordnet? Wenn ja, wie ist die Farbskala? Beim Visualisierern geht es ja darum verschiedene Aspekte bzw Byte-Klassen hervorzuheben (z.B. Ascii Text, Null-Bytes, etc) Eine andere Möglichkeit ist es die Entropie von ganzen Blöcken auf einer Farbskala darzustellen.
Angehängte Dateien:
-
verschluesselt.png
230 KB -
ausschnitt.png
21 KB
JJ schrieb: > Wenn ja, wie ist die Farbskala? Der Default ist "viridis" (links oben im Bild): https://matplotlib.org/_images/sphx_glr_colormaps_015.png Die Byte-Werte von 0 bis 255 werden auf diese Farben abgebildet. Im Anhang das Muster des ersten Megabytes einer verschlüsselten Partition und eine Ausschnittsvergrößerung davon. Natürlich sollte man bei verschlüsselten Daten nur Rauschen sehen (die die unverrauschten ersten 32kB sind der unverschlüsselte Header). Die Qualität der Verschlüsselung kann man aber über solche Bilder nicht beurteilen. Gut komprimierte unverschlüsselte Daten sehen ganz ähnlich aus. Sven B. schrieb: > test.png Bei scharfem Hinsehen erkenne ich in deinem Bild eine Datei namens "passwd". Deren Inhalt behalte ich aber besser für mich ;-)
:
Bearbeitet durch Moderator
Interessant! Ich würde aber eine andere Colormap vorschlagen - nichts fortlaufendes. ich würde die ASCII-breiche für Buchstaben z.b. Schwarz/weiss machen, und den Rest bunt. Beim Einlesen noch nach Magic-Bytes scannen und solche Bytefolgen blinken lassen.
Angehängte Dateien:
-
test.png
400 KB
Yalu X. schrieb: > Sven B. schrieb: >> test.png > > Bei scharfem Hinsehen erkenne ich in deinem Bild eine Datei namens > "passwd". Deren Inhalt behalte ich aber besser für mich ;-) Ich hab mir kurz überlegt was da drin steht aber dann einfach die Bildgröße so gewählt, dass nicht alle Pixel da sind ;) Das Bild ist übrigens tatsächlich aus dem unverschlüsselten /, vom verschlüsselten /home sieht's deutlich anders aus (s. Anhang).
:
Bearbeitet durch User
selbsternannter Kryptoexperte schrieb: > Das einzige, was du sehen wirst, ist weitgehend weißes Rauschen, weil > das per Definition das Resultat jedes effizienten > Verschlüsselungsalgorithmus ist. Yalu X. schrieb: > Natürlich sollte man > bei verschlüsselten Daten nur Rauschen sehen (die die unverrauschten > ersten 32kB sind der unverschlüsselte Header). Man merkt, dass Ihr Euch noch nicht ernsthaft mit der Praxis auseinandergesetzt habt. In der Tat gibt es viele Beispiele schlecht angewandter guter kryptografischer Verfahren, bei denen in solchen Bildern durchaus eine Struktur zu erkennen ist. Das Auge bzw. Gehirn ist dabei erstaunlich gut in der Lage, manche Arten von Unzulänglichkeiten zu erkennen. Die Probleme entstehen z.B. dann, wenn zu verschlüsselnde Datenblöcke nicht miteinander verkettet werden. Zeichnungen, die in nicht komprimiertem Format gespeichert sind, lassen sich auf diese Art und Weise sehr leicht erkennen. Mir ist durchaus bekannt, dass es Verfahren gibt, die bei *richtiger Anwendung* so gut sind, dass man nichts mehr erkennen. Aber gerade wenn es darum geht, Fremdsoftware mit Verschlüsselungsfunktion einem Schnelltest zu unterziehen, können bildliche Darstellungen durchaus wichtige Informationen liefern.
Andreas S. schrieb: > Man merkt, dass Ihr Euch noch nicht ernsthaft mit der Praxis > auseinandergesetzt habt. Die Autoren der gängigen Disk-Crypto-Software hingegen schon, und Anfängerfehler wie AES ohne Block Chaining zu benutzen wirst du da eher nicht finden. Die Erwartungshaltung, dass man da nix sieht, ist also durchaus fundiert und gerechtfertigt.
Sven B. schrieb: > Die Erwartungshaltung, dass man da nix sieht, ist also durchaus fundiert > und gerechtfertigt. Schon. Andersherum ist eine Visualisierung die optisch nach einwandfreiem Rauschen aussieht aber noch kein Beweis für eine gute Verschlüsselung. Darum sehe ich persönlich das etwas kritisch, wenn eben eine solche als Demonstration für die Qualität/Sicherheit z.B. einer Verschlüsselungssoftware genutzt wird.
Pointer schrieb: > Schon. Andersherum ist eine Visualisierung die optisch nach > einwandfreiem Rauschen aussieht aber noch kein Beweis für eine gute > Verschlüsselung. > > Darum sehe ich persönlich das etwas kritisch, wenn eben eine solche als > Demonstration für die Qualität/Sicherheit z.B. einer > Verschlüsselungssoftware genutzt wird. Definitiv ist das so, aber wenn der TO das gerne mal anschauen will, bringt es nix statt der Lösung hunderte Posts über den Sinn des Unterfangens zu diskutieren. ;)
Hallo Kryptoexperte, selbsternannter Kryptoexperte schrieb: > Das einzige, was du sehen wirst, ist weitgehend weißes Rauschen, weil > das per Definition das Resultat jedes effizienten > Verschlüsselungsalgorithmus ist. das wäre schön, aber meines Wissens nach gehört der Modus nicht zum Kryptoalgorithmus dazu. Das klassische Beispiel für die Wahl des falschen Modus findest Du z.B. hier: https://crypto.stackexchange.com/questions/14487/can-someone-explain-the-ecb-penguin Der elektronische Kochbuchmodus, der eine Bitfolge einer bestimmten Länge immer gleich verschlüsselt, gehört dazu. Dieser Modusfehler wird gerne mit dem verschlüsselten Linux-Pinguin illustriert. Wenn ich mich Recht erinnere, so hat der verwendete Modus bei in Truecrypt verwendeten Verfahren sich in neueren Versionen verändert, bzw. verbessert, weil man bestimmten Modus (u-Konjugation, deswegen kein i?) Schwächen nachweisen konnte.
Sven B. schrieb: > Die Erwartungshaltung, dass man da nix sieht, ist also durchaus fundiert > und gerechtfertigt. Stimmt so pauschal nicht. Der erste Schritt beim Untersuchen von Datenblobs (wie z.B. Firmwareupdates, Archive, Plattenimages, ...) ist eine Entropieanalyse. Jedes Verfahren hat eine Besonderheiten, die man erkennen kann. 2012-2015 war binwalk das Tool an sich. Hatte eine tolle 3D-Visualisierung, damit habe ich zahlreiche Images von embedded Devices terlegen können. Leider ist das Teil mittlerweile closed Source. Gibt jedoch enige Forks etc. Momentan sind binglide (https://github.com/wapiflapi/binglide) und veles (https://github.com/wapiflapi/veles) recht brauchbar. Online ist binvis (http://binvis.io) möglich. Ansonsten sind die Blogs von 2010-2014 vom binwalk-Author sehr zu empfehlen: http://www.devttys0.com/
Sven B. schrieb: > Die Autoren der gängigen Disk-Crypto-Software hingegen schon, und > Anfängerfehler wie AES ohne Block Chaining zu benutzen wirst du da eher > nicht finden. Oh, es ist schon unglaublich, wie viel absichtlich und unabsichtlich gepfuscht wird. Es gibt ja z.B. auch "verschlüsselte" USB-Speicherschniepel. Bei jedem Vergleichstest geht es u.a. um die Schreib- und Lesegeschwindigkeiten. Wer dort auch nur einen Hauch langsamer als die Konkurrenz ist, hat verloren. Wer auf Block Chaining verzichtet, holt da ggf. die paar Prozent heraus, die zwischen dem ersten und fünfzehnten Platz im Geschwindigkeitsvergleich liegen. Also wird es genau so implementiert. Vor einigen Jahren hatte die c't mal ein paar Krypto-Speicherschniepel getestet. Einer, der auf den ersten Blick besonders sicher aussah, hatte eine ordentliche numerische Tastatur zur PIN-Eingabe. Es war auch nicht möglich, anhand der Speicherorganisation irgendwelche Rückschlüsse auf die eingesetzten Verschlüsselungsverfahren zu ziehen, was eigentlich eine gute Sache war. Aber als der Tester das Speicherschniepel dann zerlegte, stellte er fest, dass für die PIN-Eingabe, und -Prüfung ein kleiner normaler Microcontroller zuständig war. Bei erfolgreicher Prüfung betätigte er dann die Chip-Enable-Leitung der Flash-Bausteine. Letztendlich wurde also gar nichts verschlüsselt. Bei den allermeisten oberflächlichen Tests wäre dies niemals herausgekommen, sondern das Teil wäre nur wegen seiner hohen Geschwindigkeit gelobt worden. Bei einem Projekt, damals noch als Angestellter, verkaufte unser Chef dem Kunden auch irgendwelche Buzzwords. Die Konkurrenz wollte irgendetwas mit DES verschlüsseln, aber behauptete er, wir würden dann natürlich 3DES einsetzen. Und mit diesem ganzen Blabla gewannen wir auch den Zuschlag. Also musste in der Kiste "irgendetwas" mit 3DES verschlüsselt werden. Der Kunde (Volkswagen) hatte von dem ganzen Krempel noch viel weniger Ahnung. Ich weiß gar nicht mehr, was wir damit verschlüsselten. Und die Möglichkeit, Schlüssel hineinzuladen und Signaturen zu prüfen, gab es natürlich auch nicht. Das 3DES stand ohne jeglichen Anwendungsfall im Raum, weil es damals "jeder" so machte.
c.m. schrieb: > ich würde die ASCII-breiche für Buchstaben z.b. Schwarz/weiss machen, > und den Rest bunt. Das funktioniert nur, wenn du weißt, dass die Datei nicht verschlüsselt ist und du weisst, wo die ASCII-Bereiche liegen. Mit UniCode stehst du damit aber schon auf dem Schlauch.
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.