Kryptografische Hashfunktion
-
Hi
Bei allen Hashfunktionen, die ich auf Wikipedia gefunden habe, muss die Länge der Nachricht vorher bekannt sein.
Kennt jemand einen kryptografischen Hash-Algo, bei dem die Länge der Nachricht nicht im Voraus bekannt sein muss?MfG
k.n.
-
Berechne den Hash eben erst, wenn die Nachricht komplett ist. Dann kennst du die Länge. Oder wenn du es "online" haben willst, dann berechnest du den Hash ebene auf Wunsch neu mit der bisherigen Nachrichtenlänge (was reichlich nutzlos ist, da das Zwischenergebnis nichts mit dem Endergebnis der ganzen Nachricht zu tun haben wird). Was spricht gegen diese Vorgehensweisen? Was hast du überhaupt vor? Vielleicht kennt jemand es viel bessere Lösungen für dein Problem, wenn du es uns nur verraten würdest.
Zusammengefasst: Wieso sollte man den Hash von einer unvollständigen Nachricht bilden wollen?
-
Eine Datei wird Blockweise(64KiB) gelesen, per One Time Pad Verfahren verschlüsselt und verschlüsselt gespeichert, bis EOF.
Dabei werde ich beim Verschlüsseln von der Datei (im unverschlüsselten Zustand) den SHA-1 Hash berechnen und in der verschlüsselten Datei speichern, um eine verlässliche (mit großer Wahrscheinlichkeit) Entschlüsselung zu gewährleisten.
Oder ist das keine gute Idee? Gibt es bessere Möglichkeiten?
Mit dem SHA-1 Hash möchte ich einfach nur kontrollieren, ob der richtige Schlüssel zum Entschlüsseln verwendet wurde.
Ich hatte nicht gründlich genug nachgedacht. Ich kann einfach während des Lesens bis EOF die h0...h4 Teile des Hashwertes Blockweise (64 Bytes) berechnen und dann, je nach Rest den letzten (bzw. die letzten beiden) 64 Bytes Block(Blöcke) dranhängen, um das Ergebnis zu bekommen.
-
krypto n00b schrieb:
bei dem die Länge der Nachricht nicht im Voraus bekannt sein muss?
Eigentlich ist das überall so, zumindest wenn du unter "im Voraus" "direkt am Anfang" meinst. Die Hashes iterieren alle über die Daten, und diese Zwischenergebnisse kann man einfach speichern. Ein Auszug aus dem Interface meiner SHA-2 Implementierung:
sha2::sha256_hasher hasher; // Datei öffnen while (/* Block lesen */) hasher.update(block, block.size()); auto /* <- array<byte, ..> */ hash = hasher.finish();Falls das eine eher theoretische Frage danach ist, warum die Hashes alle die Länge der Nachricht mit in den Hash basteln, kann ich nur mutmaßen. Ein Ziel von Hashes ist es ja gerade, dass es hinreichend teuer ist zwei Nachrichten zu finden, die den gleichen Hash erzeugen. Jetzt basieren diese Hashes aber auf einer Art Blockverschlüsselung, was bedeutet irgendein Padding braucht man unbedingt, wenn man Nachrichten beliebiger Länge hashen will. Wenn man aber einfach mit Nullen füllen würde, bedeutet das, dass eine Nachricht der Länge 14 den gleichen Hash erzeugt wie eine Nachricht der Länge 16, die in den ersten 14 Bytes mit der ersten Nachricht übereinstimmt, und sonst nur Nullbytes hat.
-
krypto n00b schrieb:
Oder ist das keine gute Idee?
Jede Möglichkeit einer guten Idee wurde praktisch ausgeschlossen in dem Moment, in dem du OTP erwähnt hast. Was willst du erreichen? Warum nimmst du kein verbreitetes Kryptoverfahren? OTP ist ein fast sicheres Zeichen, dass du sicherheitstechnisch in der vollkommen falschen Richtung unterwegs bist. Die Anwendungsszenarien in denen OTP Sinn macht sind eher theoretisch und im Computerbereich besonders selten gegeben.
-
OTP, weil ich gelesen habe, dass es eins der sichersten Verfahren ist, praktisch nicht knackbar.
-
krypto n00b schrieb:
OTP, weil ich gelesen habe, dass es eins der sichersten Verfahren ist, praktisch nicht knackbar.
Wenn da nicht im nächsten Kapitel stand, dass es praktisch unbrauchbar ist, dann schmeiß das Buch/Datei weg.
-
Unbrauchbar, wegen der erforderlichen Schlüssellänge?
-
k.n. schrieb:
Unbrauchbar, wegen der erforderlichen Schlüssellänge?
Auch. Es spricht vieles dagegen. Nachzulesen in jeder Beschreibung des Verfahrens.
-
wenn ich einen kurzen schlüssel für eine größere datei wähle, z.b. ein passwort mit 6 zeichen.
wie leicht/schwer kann man sowas entschlüsseln?
-
sehr leicht. Der Trick ist, dass du von vielen Dateien meistens den Anfang leicht bestimmen kannst. Zum Beispiel ein Fileheader in dem allgemeine Informationen über die Datei stehen, wie zum Beispiel Größe, magic number oder Programmversion. Den header zu erraten ist nicht schwer, also schaue ich einfach, welches Passwort den heeader erzeugt -> fertig.
OTP funktioneirt nur, wenn es garantiert kein Wiederholungen im Schlüssel gibt und der Schlüssel echt zufällig ist.
-
Ha-
man könnte ein Passwort als Seed für einen guten Zufallsgenerator benutzen und somit einen Schlüssel erhalten, der so lang wie die Nachricht ist.
-
.oO schrieb:
Ha-
man könnte ein Passwort als Seed für einen guten Zufallsgenerator benutzen und somit einen Schlüssel erhalten, der so lang wie die Nachricht ist.
Nein. Tödlicher Anfängerfehler bei OTP
Wird langsam klar, warum OTP Mist ist? Nicht nur, dass man die Schwierigkeit der geheimen Speicherung/Übertragung der Nachricht auf das exakt gleich schwere Problem der geheimen Speicherung/Übertragung des Schlüssels überträgt. Die ganze Sicherheit bricht bei der kleinsten Schlamperei zusammen. OTP funktioniert dann und genau dann, wenn man einen mindestens(!) gleich langen Schlüssel wie die Nachricht hat, der echt(!) zufällig und geheim ist.. Der Zufall ist eine extrem schwer zu erfüllende Bedingung und die nötige Länge des Schlüssels macht den ganzen Sinn einer Verschlüsselung kaputt, denn wenn man einen Schlüssel dieser Länge sicher speichern/übertragen kann, dann hätte man das auch gleich mit der Nachricht selber machen können. Verschlüsselung ist ein gut verstandenes Problem, die sichere Übertragung langer Schlüssel ist hingegen sehr sehr aufwändig und selbst Ansätze zur Lösung (Quantenkryptographie) machen eher Schlagzeilen durch Schwächen der technischen Umsetzung.
-
otze schrieb:
OTP funktioneirt nur, wenn es garantiert kein Wiederholungen im Schlüssel gibt und der Schlüssel echt zufällig ist.
"Beispielsweise scheuen viele Menschen bei der Kreation von möglichst zufälligen Texten vor Buchstabenverdopplungen und erst recht -verdreifachungen zurück, wohingegen echte Zufallstexte nicht selten zwei oder auch mehr identische Buchstaben in direkter Folge oder in kurzem Abstand enthalten können."
-
SeppJ schrieb:
denn wenn man einen Schlüssel dieser Länge sicher speichern/übertragen kann
Nicht ganz. Es gibt hier ein Szenario. Angenommen du bist James Bond. Dann kann man ein paar Quantenzufallsgeneratoren für dich eine ~16 GB große Datei erstellen lassen. Diese wird jetzt auf deinem Laptop gespeichert. Bei deinem Einsatz in Afghanistan kannst du jetzt bis zu 16 GB Daten verschlüsselt empfangen. (Und dabei hoffen, dass niemand diesen Laptop bekommt, aber du bist ja James Bond, also ist das kein Problem.)
-
Ich sage nicht, dass es absolut kein Szenario gibt, in dem OTP sinnvoll wäre. Aber es war bisher wirklich auf das "Spion reist ins Feindesland"-Szenario beschränkt. Quantenkryptographie ist eine neue Technik, die auch OTP zur Übertragung der eigentlichen Nachricht nutzt. Somit hätten wir zwei realistische* Szenarien. Ich vermute mal, keines der beiden liegt hier vor.
*: Man beachte, dass ich das James Bond Szenario als halbwegs realistische Möglichkeit mitzähle. Jeder möge selber einschätzen, was dies für unrealistische Szenarien bedeutet.
-
SeppJ schrieb:
Ich sage nicht, dass es absolut kein Szenario gibt, in dem OTP sinnvoll wäre.
Das war eher ein Scherz, und ich betrachte das Szenario eigentlich nicht als sinnvoll. Die Wahrscheinlichkeit, dass sein Laptop irgendwie abhanden kommt, halte ich nämlich für wesentlich größer, als dass sie es schaffen würden eine mit AES verschlüsselte Nachricht zu entschlüsseln. So müssten sie zumindest ihn selbst kriegen, nicht nur seinen Laptop, und das Foltern kostet ja auch noch etwas Zeit.
