Beste Verschlüsselung - so einfach?
-
Um das nochmal auf den Punkt zu bringen: Diese One-Time-Pads(OTP) sind theoretisch unknackbar. Man handelt sich aber ein Problem ein: Der Schlüssel muss sicher übermittelt/gespeichert werden. Und das ist der eigentliche Knackpunkt, denn wenn man den Schlüssel sicher speichern/übermitteln kann, dann kann man auch gleich die Nachricht (die genauso lang ist) sicher speichern/übermitteln ansstelle des Schlüssels.
Normalerweise hat man aber keine absolut sicheren Kommunikationskanäle, daher wird OTP in der Praxis nur sehr selten benutzt (es gibt aber praktische Anwendungen in der Quantenkryptographie, da dort das Übertragungsproblem gelöst ist). In der Regel setzt man daher je nach Anwendungszweck andere Verfahren ein, oft auch Kombinationen aus mehreren Verfahren. Ein paar Beispielverfahren zum googeln: RSA, AES. Die sind dann aber nicht mehr so einfach zu verstehen.
-
Das mit der Länge des Textes/der Datei ist ein guter Punkt.
Mir geht es eigentlich nur darum, einen "einfachen" Verschlüsselungsalgorithmus zu schreiben, nichts aufwändiges wie die gängigen Verfahren. Mich hat nur überrascht, dass mein erster Ansatz (siehe oben) schon eine (theoretisch) unknackbare Verschlüsselung darstellt.
-
Krypter schrieb:
Würde man die "Sicherheit" erhöhen, wenn man - anstatt einfach Xor zu nehmen - irgend einen wilden algorithmus mit Xor, Bitshift, Addition, Subtraktion usw einführt?
Ja und Nein. Der Algorithmus kann dadurch schwerer zu rekonstruieren sein. Das ganze läuft dann unter dem Oberbegriff Security through obscurity.
Und ein solches Verfahren, das nur "sicher" ist, weil der Algorithmus nicht bekannt ist, ist insgesamt wieder unsicher.
Früher oder später wird man den Algorithmus rausbekommen und damit jede Nachricht entschlüsseln können!
-
asdasd schrieb:
Früher oder später wird man den Algorithmus rausbekommen und damit jede Nachricht entschlüsseln können!
Nö, er hat ja immer noch das Passwortm was er ändern kann
-
Moadal schrieb:
asdasd schrieb:
Früher oder später wird man den Algorithmus rausbekommen und damit jede Nachricht entschlüsseln können!
Nö, er hat ja immer noch das Passwortm was er ändern kann
Die Anzahl an Schlüsselmöglichkeiten sinkt dadurch aber so drastisch, dass man diesen schnell berechnen kann.
-
Krypter schrieb:
Mich hat nur überrascht, dass mein erster Ansatz (siehe oben) schon eine (theoretisch) unknackbare Verschlüsselung darstellt.
das einfachste ist oft schon fast das beste. nimm z.b. einen PRNG, der aus einem passwort (also nicht aus seinem vorherigen zustand, wie rand()) eine pseudo-zufallsfolge, so lang wie deine datei, macht. das ist dann noch schöner.
z.b. 'nen sha1-hash aus dem passwort machen, daraus wieder einen sha1-hash, dahinterhängen, usw. bis die gewünschte länge erreicht ist.
-
;fricky schrieb:
Krypter schrieb:
Mich hat nur überrascht, dass mein erster Ansatz (siehe oben) schon eine (theoretisch) unknackbare Verschlüsselung darstellt.
das einfachste ist oft schon fast das beste. nimm z.b. einen PRNG, der aus einem passwort (also nicht aus seinem vorherigen zustand, wie rand()) eine pseudo-zufallsfolge, so lang wie deine datei, macht. das ist dann noch schöner.
z.b. 'nen sha1-hash aus dem passwort machen, daraus wieder einen sha1-hash, dahinterhängen, usw. bis die gewünschte länge erreicht ist.
Das kling sehr schlau. Ist es aber wie so oft nicht. Die sha1-Folge ist doch genau das Verwenden des vorherigen Zustands. Welche Aussagen gibt es nochmal über die Periodenlänge von sha1-Ketten? Und dann kannste deinen Pseudo-Zufallszahlengenerator, auch den mit sha1, so pfiffig machen, wie Du willst, bei einem Passwort aus drei Dezimalziffern gibt es nur 1000 Möglichkeiten. Ein zu kleiner Schlüsselraum läßt sich nicht korrigieren, indem man viel Rechenzeit für nichts verbrät.
-
Du solltest noch RC4 mit dem Hash verknüpfen um eine monoalphabetische Substitution auf Bitebene zu verhindern. Dann kannst du mit Public Key Cryptography einen RSA PRNG Codekey zur asymmetrischen Signatur hinzufügen und erzielst eine dem One-Time-Pad änhlich, aber mit hybrider Verfahrenssicherheit ohne dabei auf Hashkollisionen der PNG Tripel zu stoßen.
-
volkard schrieb:
Das kling sehr schlau. Ist es aber wie so oft nicht. Die sha1-Folge ist doch genau das Verwenden des vorherigen Zustands.
klar, ist mir schon während des schreibens aufgefallen. aber das sollte trotzdem schwer zu knacken sein, weil jedes einzlne bit des passworts einfluss auf die ganze folge hat. ich hab so'ne ähnlich sha1-ketten-xor-verschlüsselung mal implementiert (allerding war der in input für sha1 vorheriger hash xor voheriger verschlüsselter datei-block), das ergebnis ist wirklich ein übler bitsalat, an dem sogar http://www.cryptool.org/ nix zu meckern hatte.
volkard schrieb:
Ein zu kleiner Schlüsselraum läßt sich nicht korrigieren, indem man viel Rechenzeit für nichts verbrät.
musste eben lange passwörter wählen, schön mit sonderzeichen, gross/kleinschreibung und ziffern drin.
-
Verschüsselungsexperte schrieb:
Du solltest noch RC4 mit dem Hash verknüpfen um eine monoalphabetische Substitution auf Bitebene zu verhindern. Dann kannst du mit Public Key Cryptography einen RSA PRNG Codekey zur asymmetrischen Signatur hinzufügen und erzielst eine dem One-Time-Pad änhlich, aber mit hybrider Verfahrenssicherheit ohne dabei auf Hashkollisionen der PNG Tripel zu stoßen.
Daran habe ich auch gedacht. Oder ich hätte daran gedacht, wenn ich wenigstens mit der Hälfte Deiner Begriffe was anfangen könnte
.
Immerhin weiß ich so viel über Verschlüsselung, dass ich weiß, dass ich das den richtigen Experten überlassen sollte.Aber Du bringst es eigentlich trotzdem auf den Punkt. Verschlüsselung ist ein kompliziertes Thema und man sollte eher bewährte und getestete Algorithmen verwenden, als eigene erfinden. Eigene sind praktisch immer schlechter.
-
tntnet schrieb:
Immerhin weiß ich so viel über Verschlüsselung, dass ich weiß, dass ich das den richtigen Experten überlassen sollte.
verdirb dem OP doch nicht den spass. wenn jeder so denken würde, dann wären wir heute immer noch bei der cäsar-chiffre *fg*
-
Bei einer Verschlüsselung zählt nicht der Algo allein, sondern man muß immer das ganze System betrachten inklusive der Frage welche Art von Daten denn jetzt verschlüsselt werden sollen...
Beispiel... Mein Vorgänger hatte die Aufgabe ein Lizenzfile zu verschlüsseln. In dem Lizenzfile wurden Lizenzflags als Bitfeld gespeichert. (1 bit = 1 lizenzfeature). As Schlüsselalgo wählte der Kerl nen Stream-Cypher.
Alles was man tuen mußte war mittels Hex-Editor an der richtigen Stelle des Files ein Bit inverten um das zugehörige Lizenzflag an/ oder auszuschalten. Man brauchte ncihtmal das Passwort dazu. (Und die Geschäftsführung hat echt blöde geguckt...)
Krypter schrieb:
Das mit der Länge des Textes/der Datei ist ein guter Punkt.
Mir geht es eigentlich nur darum, einen "einfachen" Verschlüsselungsalgorithmus zu schreiben, nichts aufwändiges wie die gängigen Verfahren. Mich hat nur überrascht, dass mein erster Ansatz (siehe oben) schon eine (theoretisch) unknackbare Verschlüsselung darstellt.I want to move to theorie, cause in theorie everything works...
-
loks schrieb:
Bei einer Verschlüsselung zählt nicht der Algo allein, sondern man muß immer das ganze System betrachten inklusive der Frage welche Art von Daten denn jetzt verschlüsselt werden sollen...
Beispiel... Mein Vorgänger hatte die Aufgabe ein Lizenzfile zu verschlüsseln. In dem Lizenzfile wurden Lizenzflags als Bitfeld gespeichert. (1 bit = 1 lizenzfeature). As Schlüsselalgo wählte der Kerl nen Stream-Cypher.
Alles was man tuen mußte war mittels Hex-Editor an der richtigen Stelle des Files ein Bit inverten um das zugehörige Lizenzflag an/ oder auszuschalten. Man brauchte ncihtmal das Passwort dazu. (Und die Geschäftsführung hat echt blöde geguckt...)
^^muss aber trotzdem ein mieser algo gewesen sein. wenn man ein bit im cypher text flippt, sollte bei einer halbwegs guten verschlüsselung nach dem ent-crypteten einiges kaputt sein. nächstes mal häng das dran: http://www.javvin.com/networksecurity/MessageIntegrityCode.html
bzw. ein CRC, der tuts auch.
-
;fricky schrieb:
loks schrieb:
Bei einer Verschlüsselung zählt nicht der Algo allein, sondern man muß immer das ganze System betrachten inklusive der Frage welche Art von Daten denn jetzt verschlüsselt werden sollen...
Beispiel... Mein Vorgänger hatte die Aufgabe ein Lizenzfile zu verschlüsseln. In dem Lizenzfile wurden Lizenzflags als Bitfeld gespeichert. (1 bit = 1 lizenzfeature). As Schlüsselalgo wählte der Kerl nen Stream-Cypher.
Alles was man tuen mußte war mittels Hex-Editor an der richtigen Stelle des Files ein Bit inverten um das zugehörige Lizenzflag an/ oder auszuschalten. Man brauchte ncihtmal das Passwort dazu. (Und die Geschäftsführung hat echt blöde geguckt...)
^^muss aber trotzdem ein mieser algo gewesen sein. wenn man ein bit im cypher text flippt, sollte bei einer halbwegs guten verschlüsselung nach dem ent-crypteten einiges kaputt sein. nächstes mal häng das dran: http://www.javvin.com/networksecurity/MessageIntegrityCode.html
bzw. ein CRC, der tuts auch.
XOr-basierter Streamcypher ohne Checksumme. Checksum hatte der Kerl explizit rausgenommen weil das ja nur unnötig Performance kostet... Ich sagte nie das mein Vorgänger ein guter Entwickler war ;))
-
;fricky schrieb:
Krypter schrieb:
Mich hat nur überrascht, dass mein erster Ansatz (siehe oben) schon eine (theoretisch) unknackbare Verschlüsselung darstellt.
das einfachste ist oft schon fast das beste. nimm z.b. einen PRNG, der aus einem passwort (also nicht aus seinem vorherigen zustand, wie rand()) eine pseudo-zufallsfolge, so lang wie deine datei, macht. das ist dann noch schöner.
z.b. 'nen sha1-hash aus dem passwort machen, daraus wieder einen sha1-hash, dahinterhängen, usw. bis die gewünschte länge erreicht ist.
Klingt nach keiner guten Idee. Wenn man zB Teile des Plaintextes kennt (zB weil es sich um ein bestimmtes Protokoll oder Dateiformat handelt oder man sogar den Plaintext frei wählen kann), kann man einzelne bytes einfach dekodieren. Da man die Länge des Schlüssels kennt (sha1 sind iirc 20byte. Also äußerst kurz) reduziert jedes bekannte byte den Aufwand dramatisch. Bei 20 Byte ist es ja sogar nicht unwahrscheinlich, dass man direkt einen ganzen "Schlüssel" ermitteln kann. Da alle folgenden Schlüssel abgeleitet sind, lässt sich der Rest einfach entschlüsseln.
Aber vermutlich gibt es noch zahlreiche weitere Schwachstellen. Ich kenne mich nicht genug mit Kryptographie aus und auch nicht mit SHA1. Aber ich nehme an, dass jemand mit ein bisschen Ahnung das ganze relativ leicht knacken kann. (Einfach mal auf sci.crypt oä fragen)
Also keine gute Idee, wie üblich wenn Ahnungslose ihre eigenen Verfahren basteln. Daher sollte man entweder vorher entsprechende Literatur und Papers studieren, damit man weiß was man tut und mit den entsprechenden Leuten diskutieren und seine Arbeiten veröffentlichen oder man macht das einfachste und nimmt ein bestehendes bereits implementiertes Verfahren und spart sich die ganze Mühe.
-
rüdiger schrieb:
Klingt nach keiner guten Idee.
war nur 'ne idee, wie man aus einem passwort eine lange, zufällig erscheinende bitfolge machen kann, um nicht wie bei OTP riesig lange schlüssel zu haben. mit einem sogannannten 'shrinking generator' könnte es auch gehen, wenn man passwort und generator-polynom geheimhält. für kryptologen ist das alles vermutlich sicherheitstechnisch ein witz, aber der durchschnittshacker könnte schon kopfschmerzen bekommen.
-
;fricky schrieb:
rüdiger schrieb:
Klingt nach keiner guten Idee.
war nur 'ne idee, wie man aus einem passwort eine lange, zufällig erscheinende bitfolge machen kann, um nicht wie bei OTP riesig lange schlüssel zu haben. mit einem sogannannten 'shrinking generator' könnte es auch gehen, wenn man passwort und generator-polynom geheimhält. für kryptologen ist das alles vermutlich sicherheitstechnisch ein witz, aber der durchschnittshacker könnte schon kopfschmerzen bekommen.
OTP ist einfach Blödsinn. Es ist ein theoretischer Spaß. Aber einfach in keiner Weise praktikabel und auch kein guter Ausgang für den Entwurf eines eigenen Verfahrens. OTP hat wirklich in dieser ganzen Welt nur einen Zweck: Es dient als Indikator für Personen die absolut keine Ahnung von Kryptographie haben. Sobald jemand erzählt wie toll OTP doch ist oder einem etwas "(so gut) wie OTP" verkaufen will, weiß man dass es sich um einen Troll handelt und man ihn nicht ernst nehmen sollte. Das ist der einzig sinnvolle Einsatz von OTP.
Wenn ihr mir nicht glauben wollt, dann lest was Bruce Schneier zu OTP sagt und der Mann hat - im Gegensatz zu uns allen hier - wirklich Ahnung wovon er spricht.
-
rüdiger schrieb:
OTP ist einfach Blödsinn. Es ist ein theoretischer Spaß. Aber einfach in keiner Weise praktikabel und auch kein guter Ausgang für den Entwurf eines eigenen Verfahrens.
ja, echtes OTP, wegen der einschränkung der langen keys und der nur einmaligen verwendung. aber die XOR-verknüpfung selbst ist nicht der schwachpunkt. sogar AES verwendet in den MixColumns- und AddRoundKey- unterroutinen XOR, um alles kräftig durchzurühren. ich gebe dir das verschlüsslte byte 0x7e und du kannst mir jetzt sicher sagen, aus welchen bytes ich es zusammengesetzt habe. das eine ist der schlüssel und das andere der klartext.
-
Krypter schrieb:
Hallo,
Ich habe folgenden Algorithmus zum verschlüsseln von Dateien geschrieben:
//...
[/cpp]Gibt es eine Verschlüsselung, die "Sicherer" ist?
//...
Hat die Qualität des PNG in Zeile 6 auswirkungen auf die Sicherheit?Ja, sehr viele. Und die Qualität des PRNG ist entscheidend für die Sicherheit. rand() ist ein linearer Kongruenzgenerator. das bedeutet, dass ich, sobald ich wenige Bytes kenne, den seed errechnen kann. Und habe ich den seed(und damit den verwendeten Schlüssel), kann ich die komplette Nachricht entschlüsseln. Das geht ziemlich einfach, wenn deine Datei einen Dateiheader hat, den ich kenne. Das Teil zu knacken, lernst du in den ersten 3 Wochen einer Krypto-Vorlesung.
Würde man die "Sicherheit" erhöhen, wenn man - anstatt einfach Xor zu nehmen - irgend einen wilden algorithmus mit Xor, Bitshift, Addition, Subtraktion usw einführt?
xor hat erstmal perfekte kryptographische Eigenschaften, von da wirst du dort nicht wesentlich was ändern können. Du kannst nur sicherer werden, wenn du deinen Generator komplizierter machst. In der Praxis benutzt man dafür nichtlineare diskretisierte surjektive Funktionen(so genannte S-Boxen). Dabei verwurschtelst du im Generator die Schlüsselbits immer wieder mit einer Funktion die nicht invertiert werden kann (und die selber eine möglichst zufällig aussehende Abbildung hat). Wie eine gute S-Box aussieht, ist pure Magie.
Schau dir mal DES an. Ist zwar nach heutigem Standard absolut veraltet(der Schlüsselraum ist mit 2^56 zu klein), aber er ist als 3DES immer noch sehr sicher und benutzt nur S-Boxen, Permutationen und xor.
-
otze schrieb:
Wie eine gute S-Box aussieht, ist pure Magie.
hier'n ziemlich guter text zum innenleben von AES, incl. erklärung der GF(2^n)-arithmetik, wie die s-boxes aufgebaut sind und so: http://www.rose-hulman.edu/Class/ma/holden/Home/OldFiles/Papers/S/schaefer-s-aes.pdf
^^falls sich wer für die interna interessiert.
