Frage zu folgender Verschlüsselung

Z

Zhavok

0
Hallo zusammen,

ich habe vor kurzer Zeit angefangen mich für das Thema Kryptographie zu interessieren und versuche gerade selbst einen kleinen Algoríthmus zu basteln. Mir ist klar, dass man in der Praxis möglichst fertige Libs verwenden sollte um seine Produkte zu sichern, deshalb betrachtet das ganze eher als eine kleine Idee, welche ich nicht in irgendeiner Form von Software nutzen werde. Und zwar hatte ich einen ganz simplen Gedankengang. Ich hatte überlegt, aus einem Passwort einen Hash zu generieren. Und aus dem Hash, dann wieder einen Hash, welchen ich hinter den ersten hänge. Das ganze mache ich solang, bis mein String so lang ist wie der Plaintext, den ich verschlüsseln möchte. Dannach XORe ich einfach meinen Plaintext mit dem langen erstellten Hashstring. Mir ist klar, dass diese Möglichkeit viel zu einfach ist um gut zu sein. Außerdem ist es eigentlich nicht wirklich schlau sich einen solangen String zu bauen. Gerade bei großen Dateien stell ich mir das sehr katastrophal vor. Aber für kleine Schnipsel oder kurzen ASCII - Text könnte das ganze doch funktionieren oder? Wie schon gesagt, ich weiß, dass die Methode nicht sehr gut ist, aber ich wüsste auch nicht direkt, was bis auf die oben geschriebenen Dinge dagegen spricht, bzw wo ein Sicherheitsrisiko steckt. Eigentlich ist es ja nichts anderes als das One-Time-Pad mit einem Hash als Key.

Ich freue mich auf eure Antworten :):thumb_up:
 
Zuletzt bearbeitet:
Von welchen Werten soll dein Hash abhängen? Nur vom Klartext und einem Salt, wie so alle gängigen Hashs? Dann ist dein Salt der unter allen Umständen zu schützende Key.
 
Eigentlich nur vom Passwort. Salts sind ja meist zufällig. Somit könnte man nur entschlüsseln wenn man Passwort und Salt hat. Es geht mir hier nur um symmetrische Verschlüsselung. Einfach Passwort nehmen, daraus Hash generieren. Daraus dann wieder Hash generieren und erstem Hash anhängen. Aus dem beiden Hashs wieder Hash bilden und den beiden angängen usw. bis man die Länge der eigentlichen Nachricht erreicht hat. Also ein langer String aus Hashs. Dann einfach die Nachricht mit dem langen String XORen. So ist meine Vorstellung. Zumindest für kleine Dateien.
 
D.h. du erzeugst aus deinem Passwort mehrere aneinander gehangene Hashes und wendest dann das OTP an?

Ein Salt muss nicht zufällig sein. Das wichtige am Salt ist, dass du diesen Wert immer wieder rekonstruieren kannst - im Gegensatz zum Pepper. Ein Salt wird idR mitgespeichert, der Pepper nicht. Ein Pepper ist wirklich rein zufällig.
 
Shalec hat gesagt.:
D.h. du erzeugst aus deinem Passwort mehrere aneinander gehangene Hashes und wendest dann das OTP an?
Zum Vergrößern anklicken....

Ja genau. Das war der Plan. Sicher könnte man auch ein Salt mit beim generieren einbeziehen. Die Frage die mich aber mal vom Salt abgesehen interessiert ist, wie sicher das ganze überhaupt wäre.

Ich habe allgemein immer wieder kryptografische Ideen und stelle mir dann die Frage wie sicher etwas ist. Wie kann ich da Abhilfe schaffen? Nur weil selbst keine Möglichkeit kenne meine Algorithmen zu knacken, heißt es ja nicht, dass es nicht möglich ist. Im Gegenteil, ich bin mir sogar sehr sicher, dass man die alle knacken kann ?.
 
So sicher, wie die Länge deines Passwortes bzgl. Bruteforce es zulässt oder die verwendete Hashfunktion ist.

Guck dir mal das große Gebiet der "Hashbasierten Kryptographie" an, falls dich das interessiert.

Die Sicherheit des OTP wirst du nicht erreichen. Selbst wenn du eine Key-Expansion-Funktion (ala AES) verwendest, um dein Passwort größer zu machen und um so für jeden Hash einen anderen Wert zu nehmen, findet man dort Schwachstellen, da jede Form von Determinismus negativ ist.

Du kannst ja auch mal eine solche Aufgabe vorbereiten und diese hier im Board einreichen. Wichtige Fakten lieferst du nach dem Kerkhoffschen Prinzip

Dann siehst du, ob deine Verschlüsselung gebrochen werden kann, oder nicht so leicht ;)
 
Vielen Dank schonmal. Evtl stell ich bald mal nen kleinen Algorithmus hier ins Forum. Vielleicht auch in Form eines kleinen Gewinnspiels falls den jemand knackt :)
 
Also als Laie frage ich mich, was denn dein Passwort, mit Hash oder nicht, überhaupt für eine Rolle spielt?Am Ende benutzt du XOR und da ist der plaintext und der chiffreblock interessant. In deinem Fall ist der Block das Ergebnis einer Hasharie.Wenn ich aber einen Hash und Plaintext habe, ist das Passwort irrelevant..Du könntest also auch einfach mittels eines brauchbaren randomizers einen Key/chiffre erzeugen, der so lang ist, wie dein Plaintext.Unterm Schnitt bleibt es aber bei der bekannten XOR Verschlüsselung und die ist aus bekannten Gründen eben nicht erste Wahl.Mit einem zufallsmäßigen ROT-random Key stehst du imho sicherer da.Bitte um Korrektur.
 
Aus dem Passwort wird der Hash erzeugt. Das bedeutet zum Beispiel folgendes. Mein Passwort ist "Flugzeug". Daraus generiere ich den Hash. Dann XORe ich den Hash mit dem Plaintext und bekomme das Chiffrat. Dann gebe ich dem Empfänger ebenfalls das Passwort "Flugzeug". Dieser generiert dann wieder einen Hash daraus, welche exakt gleich mit meinem ist. Dann wieder XOR erzeugt wieder den Plaintext. Nehme ich nen Zufallswert, dann müsste ich dem Empfänger diesen mitteilen. Und Randombytes lassen sich schlechter merken als ein Passwort. Aber gut, davon mal ganz abgesehen... Gibt es ein gutes Buch über Kryptographie? Wo man vielleicht lernt, wie man welche Vorgehensweisen iAallgemeinen eine Verschlüsselung schwer knackbar machen? Wo vielleicht auch Mathematische Zusammenhänge erklärt werden? (Die S-Boxen im AES haben ja auch ihre Bewandtnis).Nach wie vor ist mir klar, dass ich beim programmieren von Software für dritte keine eigenen Kryptoalgorithmen nehme :)
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben