Diskussion über Effektivität eines Verschlüsselungsverfahrens



  • Zusatz von Moderator : Split aus diesem Thread, betrifft den Code aus dem ersten Post.

    Tim06TR schrieb:

    Der folgende Code ist ein sehr simples, aber effektives (zeitlich) Verschlüsselungsverfahren.

    Vermutlich nicht einmal zeitlich. Das fällt bestenfalls unter Verschleierung; mit Verschlüsselung hat das nichts zu tun, und das ist dir hoffentlich klar.



  • audacia schrieb:

    Tim06TR schrieb:

    Der folgende Code ist ein sehr simples, aber effektives (zeitlich) Verschlüsselungsverfahren.

    Vermutlich nicht einmal zeitlich. Das fällt bestenfalls unter Verschleierung; mit Verschlüsselung hat das nichts zu tun, und das ist dir hoffentlich klar.

    Bitte ?

    Ich lasse die Zeichen nicht nur in Zahlen umwandeln ?

    Ohne eine der beiden Codes lässt sich mit den Zahlen nichts anfangen, UNMÖGLICH!
    Das entsclüsseln zu wollen ist zwechklos ohne die andere Hälfte.
    Das geht doch eindeutig unter Verschlüsselung, auch wenn ich das als kryptischen Zahlen lasse.

    PS: Ja ich weiß, dass man mit dem ea und eo auch sofort sagen kann, um ob es sich um eine gerade oder ungerade Zahl handelt, aber das hilft nicht viel.
    Das Verfahren ist für Komplexere Texte gedacht.
    6 MB dauern... ungf. 23 sekunden.



  • Tim06TR schrieb:

    Ohne eine der beiden Codes lässt sich mit den Zahlen nichts anfangen, UNMÖGLICH!

    Denkste.

    Zufällig hatte ich gerade Lust dazu(tm), und so habe ich mal einen kleinen heuristischen Decoder gebaut, der ohne den Schlüssel auskommt und den Text approximativ reproduziert. Du findest ihn hier (inklusive Quelltext, damit du auch verifizieren kannst, daß ich nicht trickse 😉 ), und so sieht es aus, wenn man ihn mit einem Beispieltext füttert.

    Das hat mich vielleicht eine halbe Stunde gekostet, und ich bin nicht mal ein geübter Cracker. Der Decoder verwendet eine sehr simple Heuristik, die nicht auf den Kontext achtet. Mit Kontextsensitivität könnte man da wesentlich mehr herausholen. Aber es ist schon recht leserlich dafür, daß es eigentlich "UNMÖGLICH!!!11" ist, findest du nicht? 😉

    Du könntest mir jetzt die Arbeit erschweren, indem du die gröbsten Fehler beseitigst und etwa srand() einmal aufrufst - dann vervielfacht sich nur die Zeit, die mein Decoder braucht, weil ich mehr oder weniger alle Möglichkeiten durchprobieren würde. Du könntest den Quelltext unter Verschluß halten - dann muß ich eben dein Programm disassemblieren. Aber das verzögert den Prozeß alles nur; für einen Profi sind das keine ernstzunehmenden Hindernisse.

    Tim06TR schrieb:

    Das entsclüsseln zu wollen ist zwechklos ohne die andere Hälfte.

    Das ist allerdings richtig. Die eine Hälfte enthält schlichtweg nicht alle Informationen; du speicherst einen Teil der Informationen in der Key-Datei. Das führt dazu, daß nur heuristische Rekonstruktionsverfahren wie das obige möglich sind. Wenn man aber weiß, mit welchem Dateityp man es zu tun hat (meine Heuristik nimmt plain text an), hat man eine Metrik, mit der man einen Brute-force-Angriff bewerten kann - und wenn man die Metrik intelligent genug gestaltet, kann das sehr brauchbare Ergebnisse haben.

    Tim06TR schrieb:

    Das geht doch eindeutig unter Verschlüsselung, auch wenn ich das als kryptischen Zahlen lasse.

    Nein. Verschlüsselung ist eine Verschleierung, die man ohne Kenntnis des Schlüssels mit menschenmöglichem Aufwand nicht revertieren kann. Das ist ganz offensichtlich hier nicht der Fall. Weiter funktioniert ein ordentliches Verschlüsselungsverfahren derart, daß die gesamte Information der Datei erhalten bleibt (und üblicherweise wird die Datei auch nicht größer), und ein Schlüssel ist eine Bitkombination fixer Länge (etwa 128 Bit), nicht irgendein Zusatzoutput, der genauso groß wird wie die Datei selbst.

    Kryptographie ist eine ganze Wissenschaft für sich und hat eine solide mathematische Grundlage. Ich lege dir nahe, dich einmal bei den einschlägigen Wikipedia-Artikeln über alles Grundlegende zu informieren:
    http://de.wikipedia.org/wiki/Kryptographie
    http://de.wikipedia.org/wiki/Advanced_Encryption_Standard

    Wenn du Daten verschlüsseln willst, ist die einzig sinnvolle und sichere Lösung, einen herkömmlichen Algorithmus zu benutzen. Hier gibt es etwa eine ausführliche Implementation für Delphi, die du auch in C++Builder benutzen kannst.

    Tim06TR schrieb:

    6 MB dauern... ungf. 23 sekunden.

    Na siehst du, dann ist es ja nicht einmal zeitlich effizient. Eine gut optimierte Implementation von einem Verschlüsselungsalgorithmus wie AES schafft durchaus 40 MB/s (etwa diese hier). Ganz abgesehen davon, daß sie bei weitem nicht so viel Output produziert. (Und schon gar nicht eine Key-Datei, die so groß ist wie der Datensatz selbst.)



  • Ui da bin ich baff.
    Ich hätte vermutet, dass das Verfahren mehr in die Richtung des OneTimePads tendiert.

    Das One-Time-Pad benötigt einen Schlüssel, der genauso lang ist wie die Nachricht selbst. Um beispielsweise die gesamten Daten einer Festplatte zu verschlüsseln, ist eine zweite Festplatte (mit mindestens gleicher Größe) zur Speicherung des Schlüssels nötig
    

    Es kann auch mit beliebig hoher Rechenleistung nicht gebrochen werden.

    Aber wie man sieht ist dieses Verfahren, also MEINS, knackbar. (Wenn auch recht dürftig).
    Aber wenn man Code X4 (dieses hier) mit Code X3 vergleicht. Ist das hier ein "schnelles" System. Dazu kommt, dass der Schlüssel nicht nur gleich groß oder etwas größer ist (ca. 5 mal so groß), Ist der Schlüssel da 255 mal so groß.
    Ich denke nicht, dass man da noch von effizienz reden kann 😃 .

    Ich wollt was "eigenes" kreieren, bei dem der Schlüssel nicht so eine epische Größe erreicht. Aber das das so "leicht" knackbar ist. 😕

    Hab mir den Quelltext mal angesehn...

    //ShowMessage("GotIt"); // WTF?

    😃 Huch war das da drin ?

    Wenn Code X3 nicht die HÖLLE wäre würd ich das auch noch reinstellen, so aus Spaß 😃 😃 😃

    EDIT: Würde der Text KEINEN Sinn ergeben wäre es nach wie vor unlösbar !

    EDIT 2: Ahh ich errinnere mich wieder, an das was du da ausgenutzt hast !
    Ich überlege gerade, was man da machen kann ?
    Code X3 benutzen ?



  • Dieser Thread wurde von Moderator/in akari aus dem Forum VCL (C++ Builder) in das Forum Rund um die Programmierung verschoben.

    Im Zweifelsfall bitte auch folgende Hinweise beachten:
    C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?

    Dieses Posting wurde automatisch erzeugt.



  • Verschlüsselung ist ein schwieriges Thema, an das man sich als Nichtexperte nicht heranwagen sollte.
    Wenn du aber Spaß am Algorithmen entwickeln hast, würde ich dir empfehlen, einen Kompressionsalgorithmus zu entwickeln. Da kann man auch ohne jegliche Vorkenntnisse gute Erfolge erzielen. Und es ist dann auch ein Erfolgserlebnis, wenn man es zum ersten Mal geschafft hat, eine Datei besser als zip/deflate zu komprimieren. 🙂



  • sej ich das richtig, dass dein Verschlüsselungsverfahren nichtmal sowas wie einen Key hat und du dich ganz auf rand() verlässt?

    Dann hast du ein massives Problem, weil rand wirklich einfach knackbar ist. Rand ist eben kein True-RNG wie es beim OTP erfordert ist, und nicht einmal ein CS-RNG (kryptographisch sicherer RNG). Um ganz genau zu sein, ist das Ding sogar nur linear! Wenn man also nur ein bisschen vom Plaintext kennt (Dateiheader!), kann man sich den Seed berechnen und kann so die Verschlüsselung knacken.

    EDIT: Würde der Text KEINEN Sinn ergeben wäre es nach wie vor unlösbar !

    Und eben das ist kein Sicherheitskriterium. So musst du dich auf Eigenschaften des Plaintexts verlassen, eben dass er keinen Sinn hat. Aber wann ist das schon der Fall? Eine Eigenschaft von Daten ist, dass diese eine Struktur haben. Und die ist oftmals bekannt. Hinzu kommt, dass aufgrund der Funktionsweise von Rand auch eine Struktur des Ergebnisses bekannt ist. Es kommen also nicht mehr alle möglichen Ergebnisse in betracht, sondern nur noch die, die auch durch Rand erzeugt werden können.



  • Athar schrieb:

    Und es ist dann auch ein Erfolgserlebnis, wenn man es zum ersten Mal geschafft hat, eine Datei besser als zip/deflate zu komprimieren. 🙂

    Vor allem sie dann wieder ausgepackt zu bekommen...



  • Tim06TR schrieb:

    Ich hätte vermutet, dass das Verfahren mehr in die Richtung des OneTimePads tendiert.

    Vergiss OTP. OTP gibt es nicht als halbes oder ganzes. Ein Verfahren kann nicht "in die Richtung OTP" gehen. Entweder es ist 100% OTP oder es ist Blödsinn. Aber vergiss OTP. OTP ist einfach theoretischer Schwachsinn, der nicht sinnvoll und praktikabel ist. Wenn du den Schlüssel nicht 100% zufällig erzeugst (und nein, rand kommt da überhaupt nicht dran), dann ist das ganze nicht sicher. Es gibt dokumentierte Fälle, wo von Regierungen betriebene OTP Systeme geknackt wurden, weil die Schlüssel nicht zufällig genug waren (zB. von irgend welchen sowjetischen Agenten oder vom deutschen Außenamt im 2.Wk). Und die haben dafür schon extra Maschinen eingesetzt. => Vergiss OTP. Es ist einfach nur eine nette Idee, aber überhaupt nicht praktikabel.

    Außerdem ersetzt OTP ja nur das Problem der Verschlüsselung (ein recht gut verstandenes Problem, für das es zahlreiche praktikable Verfahren (zB. AES) gibt) gegen ein Problem des Schlüsselaustauschs (ein unverstandenes, unsicheres und kompliziertes Problem).

    Vergiss OTP!

    Wenn du mit nicht glaubst, dann lies was Bruce Schneier (anerkannter Kryptographie-Experte) dazu sagt: http://www.schneier.com/crypto-gram-0210.html#7

    (P.S. Wir bräuchten wirklich mal einen FAQ Eintrag zu OTP. Leider kommen immer genug Leute die meinen, dass sie OTP implementieren würden oder anderen Leuten OTP empfehlen. OTP hat eigentlich nur sinnvollen einen Zweck: Man kann sofort erkennen, ob jemand keine Ahnung von Kryptographie hat: Leute die meinen OTP zu implementieren oder OTP empfehlen, haben einfach keine Ahnung von Kryptographie)

    Wenn du dich mit echter Kryptographie (und nicht mit Blödsinn ala OTP) befassen willst, dann schau dir folgendes Buch an. Das ist eine ziemlich umfangreiche (aber nicht ganze leichte) Einführung

    Applied Cryptography | ISBN: 0471117099



  • rüdiger schrieb:

    Vergiss OTP....Aber vergiss OTP.
    OTP ist einfach theoretischer Schwachsinn, der nicht sinnvoll und praktikabel ist.

    😃

    Wikipedia schreibt:
    * der Einmalschlüssel muss geheim bleiben,
    * der Einmalschlüssel muss unvorhersagbar zufällig sein und
    * der Einmalschlüssel darf nur einmal verwendet werden!

    Damit sollte eigentlich alles zur korrekten Verwendung des OTP-Verfahrens gesagt sein.



  • 1. @ rüdiger: Ein OTP im Kaffe zu viel ?

    2. Ja mir ist aufgefallen, dass Verfahren cx4 banane ist.

    3. Wie nennt man das noch, wenn der Empfänger einen eigenen key hat, der zum entschlüsseln gebraucht wird ? a... as... an...
    Um zu verhindern, dass ein dritter den Schlüssel in der Übertragung abfängt und den Text entschlüsseln kann ?

    HABS SELBST -> asymetrisch

    4. was sagt ihr zu dem, was ich in Punkt 3 suche, wird das überhaupt noch genutzt ?

    5. Ist ein Tausch aller Zeichen vor der eigentlichen Verschlüsselung ratsam, bringt das was ? (ist in cx3 mit drin)

    6. Und ein Tausch hinterher ?



  • Der private/eigene Schlüssel ist zum Verschlüssel da. Man kann auch mit dem öffentliche Schlüssel des Empfänger machen für die Verschlüsselung ist das egal, allerdings will doch der Empfänger prüfen ob die Nachricht Authentisch ist und des Quelle überprüfen. Das geht dann nicht.



  • Zeus schrieb:

    Der private/eigene Schlüssel ist zum Verschlüssel da.

    Falsch.

    Verschlüsselt wird mit dem öffentlichen Schlüssel des Empfängers. Damit wird sichergestellt das die Nachricht NUR vom Empfänger mit dessen privaten Schlüssel entschlüsselt werden kann.

    Umgekehrt wird der private Schlüssel zum signieren benutzt, so kann jeder mit dem öffentlichen Schlüssel des Senders die Authenzität der Nachricht prüfen.

    Denkt nur mal drüber nach, wenn man mit dem eigenen privaten Schlüssel eine Nachricht verschlüsselt, dann könnte jeder der im Besitz des öffentlichen Schlüssels ist diese ja entschlüsseln... Was per Definition des Begriffes "öffentlicher Schlüssel" ja praktisch Jeder ist...



  • Tim06TR schrieb:

    3. Wie nennt man das noch, wenn der Empfänger einen eigenen key hat, der zum entschlüsseln gebraucht wird ? a... as... an...
    Um zu verhindern, dass ein dritter den Schlüssel in der Übertragung abfängt und den Text entschlüsseln kann ?

    HABS SELBST -> asymetrisch

    4. was sagt ihr zu dem, was ich in Punkt 3 suche, wird das überhaupt noch genutzt ?

    Ähm, googel mal nach den Begriffen SSL, SSH, VPN, PGP, Zertifikate... Zähl die Hits und dann entscheide selber ob das "noch" genutzt wird...(bzw. versuch mal Bereiche im Internet zu finden in denn asymetrische Verschlüsselung _nicht_ genutzt wird...)



  • ad 4: ja, wird genutzt, und wie auch noch. So ca. genau überall 🙂

    Allerdings wird es so gemacht, dass nur ein zufällig generierter Schlüssel mittels RSA, EC oder einem anderen asymmetrischen Verfahren verschlüsselt wird. Dieser Schlüssel wird dann verwendet die eigentlichen Daten mit symmetrischen Verfahren wie AES, ... zu verschlüsseln.

    Und dass 23 Sek. für 6 MB = ca. 260kB/sec ziemlich langsam sind, wurde ja schon erwähnt.

    Tip: man muss den Code nur angucken um zu sehen dass er langsam ist. Grund: du machst einige unnötige Dinge, die gröber bremsen. Schonmal dass du mit std::string, Streams und Binär<->Dezimal-Wandlung arbeitest ist ein Performance Killer.



  • Athar schrieb:

    Wenn du aber Spaß am Algorithmen entwickeln hast, würde ich dir empfehlen, einen Kompressionsalgorithmus zu entwickeln. Da kann man auch ohne jegliche Vorkenntnisse gute Erfolge erzielen. Und es ist dann auch ein Erfolgserlebnis, wenn man es zum ersten Mal geschafft hat, eine Datei besser als zip/deflate zu komprimieren. 🙂

    IMO ein sehr guter Tip.
    Vor allem kann man da auch selbst die Effektivität des Verfahrens beurteilen, was bei Verschlüsselungen so-gut-wie unmöglich ist.

    Man "sieht" halt auf den 1. Blick dass es funktioniert 🙂


Anmelden zum Antworten