Beste Verschlüsselung - so einfach?
-
@Krypter:
Du solltest Dich erst mal mit den Grundlagen der Verschlüsselung beschäftigen. Deine Verschlüsselung sieht auf den ersten Blick perfekt aus, wenn man der Schlüssel, der auf einem sicheren Weg übertragen werden muss, perfekte Zufallszahlen sind. Und schon die Erzeugung von Zufallszahlen ist schon eine Wissenschaft für sich. Die gängigen rand()-Implementierungen erzeugen mit einem Startwert immer die gleiche Folge. Damit ist die Schlüssellänge genau so lang, wie der Startwert, da ich den Rest ja daraus berechnen kann.
Und selbst dann haben Deine verschlüsselten Daten noch Informationen, die unverschlüsselt sind. Nämlich die Länge der Quelldaten. Also wenn Deine Ausgangsdatei beispielsweise 4711 Bytes hat, dann haben Deine verschlüsselten Daten auch 4711 Bytes. Der Angreifer erfährt also etwas über Deine Quelldaten. Offensichtlich ist Dein Algorithmus also doch nicht perfekt.
Die Länge erscheint auf den ersten Blick banal, aber nehmen wir beispielsweise eine Banküberweisung, die im Textformat vorliegt und verschlüsselt wird. Wenn es ungünstig gemacht wird, könnte es sein, dass ich aus der verschlüsselten Überweisung schliessen kann, wie viele Stellen der Betrag hat. Und das ist eine Information, die in einer verschlüsselten Banküberweisung mal wirklich nicht erkennbar sein sollte.
-
Superlexx schrieb:
Blue-Tiger schrieb:
haettest du genau so gut gleich die echten Daten auf diesem Weg speichern koennen.
hätte er aber nicht zur selben Zeit machen müssen *g*. Der OTP wurde ja auch so verwendet: Agent nimmt sich lange Schlüssel mit und kommuniziert bis sie alle sind.
Word, aber der Threadersteller will ja vermutlich alle Details ueber den Algo wissen.
-
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.
