Diskussion über Effektivität eines Verschlüsselungsverfahrens
-
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ötigEs 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
-
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
