Hi
Ein Bekannter von mir hat ein Verschlüsselungsprogramm geschrieben.
Den Verschlüsselungs Algorithmus hat er selbst entwickelt.
Mittlerweile hat er auch das Patent drauf.
Nach seiner Berechnung bräuchte man 10^950 Jahre um die verschlüsselten Daten zu knacken.
Ich würde gern mal ein paar Meinungen zu dem Verschlüsselungsverfahren einholen.
Das Programm und die Beschreibungstexte hab ich angehängt.

Crossposting DP

MfG

Wenn ich das richtig sehe, ist das einfach eine Buchstaben-Substitution mit anschließender Permutation.

Ich bin kein Experte in Sachen Kryptoanalyse, aber ich halte diese Verschlüsselung nicht für besonders gut. Erstens hat man das Problem des Schlüsselaustauschs. Public-Key-Verfahren haben da schonmal einen Vorteil.
Zweitens kann man die erste Stufe sehr leicht knacken, z.B. über Häufigkeitsanalysen. Und wenn man ein paarmal in die Lage kommt, Klartext und den verschlüsselten Text in die Finger zu bekommen, ist der Code wahrscheinlich ganz schnell fürn Eimer.

Die Idee ist nicht schlecht, aber dass man auf sowas ein Patent kriegen kann...

Hi
Danke für deine Antwort.
Wie lang würde man mit einer Häufigkeitsanalyse deiner Meinung nach brauchen um den Code zu knacken?
Was ist den Beispielsweise ein besserer Verschlüsselungsalgorithmus?

MfG

Wie lange man dafür braucht, weiß ich nicht. Eine Häufigkeitsanalyse alleine reicht ja auch nicht - sooo unsicher ist das Verfahren dann doch nicht.

Fakt ist aber: Wenn ein Angreifer ein Dutzend (evtl. ein paar mehr) solcher 256-Blöcke im Original und im verschlüsselten Zustand bekommen kann, ist der Code nichts mehr wert. Übers Buchstaben zählen und vergleichen der Anzahlen kommt man an die Vertauschung ran (Phase 1), und die Positionsvertauschungen (Phase 2) sollten auch leicht über Ausschlussverfahren rauszufinden sein. Sollte nicht schwieriger sein als ein kniffliges Sudoku.
Natürlich ist das eine sehr starke Voraussetzung. Aber ich denke, dass man die Permutationen auch über Mustersuche einschränken kann, wenn man über die verwendete Sprache etwas weiß.

Bessere Verfahren: Die üblichen Verdächtigen - DES, RSA etc.

Coder hat folgendes geschrieben:

... Den Verschlüsselungs Algorithmus hat er selbst entwickelt. ... Mittlerweile hat er auch das Patent drauf. ... Crossposting DP MfG

1. wozu entwickelt er selbst einen Verschlüsselungs Algorithmus?
2. Er hat kein Patent auf den Algorithmus. Das ist nicht möglich. So etwas ist nicht patentfähig.
3. wenn er ein Patent erteilt bekommen hat, wie ist die Patent Nr.?
4. wenn, hat er eine Anmeldung. In diesem Fall würde ich mich für die Nr. der Patentanmeldung interessieren.
5. was hat Ihn die Anmeldung gekostet? Kennst Du die Kosten für Patentanmeldungen?

vgl.:
- DPMA (www.dpma.de/index.htm)
- USPTO (www.uspto.gov/)

- § 1 (2) PatG
das Patentgesetz schließt "Programme für Datenverarbeitungsanlagen" vom Patentschutz aus

@Quake User: laut dem Infofenster des Programms

Zitat:

101 21 867 erteilt am 28.08.2006

AXMD

Dann hat er wohl das Patent auf die Verschlüsselung.
Sorry, aber so genau kenn ich mich damit auch nicht aus.
Die Patent Nr ist 101 21 867
Wieviel das kostet weis ich leider auch nicht.

Ich hab meinem Bekannten diesen Thread gezeigt
und er meint ihr habt da ein wichtiges Detail vergessen.

Zitat:

Hi, die Leute haben übersehen, dass jedes von 256 Byte einen neuen Wert u n d eine neue Position bekommt. Damit ist es eine echte 2048-Bit-Verschlüsselung, d.h. in Abhängigkeit vom aktuellen Schlüssel wird ein Wert zwischen 0 und (2 hoch 2048)-1 (dezimal rund 3,2 mal 10 hoch 616) in einen scheinbar beliebigen aber durch den aktuellen Schlüssel genau definierten anderen Wert dieser Größe umgewandelt. Was nutzt es schon, wenn man vermuten kann, dass der Buchstabe 'e' zu dezimal 221 wurde, aber nicht sagen kann, welches der z.B. 40 'e' in den 256 Byte auf welche Position gehört. So kommt man mit der Kryptanalyse nicht weit, weil man am Ende ja einen sinnvollen Text haben will. Dazu müsste man schrittweise die anderen Zeichen aus dem Zusammenhang heraus ergänzen. Durch die Vertauschung der Position wird dies aber praktisch unmöglich. MfG Jörg

Würden Vorlagen und Häufigkeitsanalysen also doch nichts bringen?
Langsam wirds interessant.

Zitat:

Was nutzt es schon, wenn man vermuten kann, dass der Buchstabe 'e' zu dezimal 221 wurde, aber nicht sagen kann, welches der z.B. 40 'e' in den 256 Byte auf welche Position gehört.

Ganz einfach: Wenn man mehrere Blöcke abfangen kann, dann kann man per Auschlussverfahren die Position weiter eingrenzen (immer unter der Voraussetzung, dass man Original und Codierung abfangen kann).
Beispiel: Im ersten Block des Originaltextes kommen 20 "e" vor. Nehmen wir weiter an, der erste Buchstabe im Original ist ein "e". Jetzt hat man 20 Möglichkeiten, wohin der erste Buchstabe in einem solchen block verschoben werden kann
Dann kann man sich den zweiten Block anschauen, der ja (wenn ich das richtig sehe) mit demselben Schlüssel bearbeitet wurde. Nehmen wir an, der erste Buchstabe dort ist ein "a", und kommt 10 mal vor. Es ist sehr wahrscheinlich, dass sich die Stellen, wo das a auftaucht und die Stellen, wo das e auftaucht, sich nicht 100%ig überdecken, sondern evtl. nur 1 oder 2 Möglichkeiten übrigbleiben. Damit hat man das erste Byte des Schlüssels gefunden und kann weitermachen.

Mir ist klar, dass das eine recht starke Annahme ist (man muss ja erstmal Code und Klartext bekommen), aber wenn das passiert, und das Verfahren bekannt ist, ist es imho nichts mehr wert.

Verschlpssel mal eine Datei die nur a's enthält damit. Jedes a wird duch das selbe Zeichen ersetzt -> die Verschlüsselung ist crap.

uall@ogc hat folgendes geschrieben:

Verschlpssel mal eine Datei die nur a's enthält damit. Jedes a wird duch das selbe Zeichen ersetzt -> die Verschlüsselung ist crap.

Meinst du das in der jhc Datei dann auch nur ganz viele a stehen?
Bei mir nicht.

Dann machst du was falsch

Ja ok es stehen viele | da.
Aber es ist doch bekannt das bei normalen Verschlüsselungen ein einfaches, kleines Passwort auch nur wenig Sicherheit gewährt.

Wie auch immer.
Ich warte erstmal auf das was mein Bekannter dazu sagt, denn ich hab ja eigentlich keine Ahnung davon.

MfG

Ich hab das Programm jetzt nicht getestet oder auspobiert. Aber wenn ich mir die beiden Dateien da im Anhang angucke, dann sehe ich im Original ganz viele A's, und im Code ganze viele ³'s. Davor stehen 520 andere Zeichen. Jetzt sag bitte nicht, dass das der Schlüssel ist (520 = 512 + 8 = Schlüssellänge + Header + Integer?)...

Coder hat folgendes geschrieben:

Ich warte erstmal auf das was mein Bekannter dazu sagt, denn ich hab ja eigentlich keine Ahnung davon.

Wie wär's dann, wenn sich dein Bekannter hier registriert, sein Programm selbst vorstellt und auf eventuelle Fragen eingeht ?

AXMD

Also ich habe mal mit einer anderen Datei getestet. (Alle 256 Ascii zeichen mehrmals hintereinander)
Auch dort tritt Redundanz auf aus der man das Passwort (bzw den Decodiercode berechnen kann)

Richtige Verschlüsselungsverfahren, erstellen bei einem Code nie Redundanz. (Kannst ja mal RC4 testen)
Demnach ist die Sicherheit nicht gegeben. Denk mal negaH wird dir das im DelphiPraxis Forum genau belegene können. (hat) in er hat in diese Richtung studiert (oder studiert noch). Aber der kann dir die Sicherheit in einem kleinen Text locker widerlegen.
Also versteh ich auch nicht wie dein Bekannter das zum Patent anmelden konnte. (Naja die interessiert wohl das Verfahren dort weniger ;P) Aber er hätte es besser mal in einer Wissenschaftlichen Zeitschrift (bzw. Mathematisches Forum) veröffentlichen sollen dann hätte er sich viel Arbeit und Geld gespart. (Fürs Patent)

Diese Verschlüselung ist absolut unsicher.

Wir nehmen an das unser Schlüssel aus 512 mal 0 besteht. Das ist defakto ein regulär gültiger Schlüssel als dem Set von 2^(512* Schlüsseln.

Unser Nachricht besteht aus den Zahlen 256 mal die 0.

Die Verschlüsselung erzeugt einen Output der defakto aus 1 Byte besteht -> nämlich 0.

Warum ?

Der Schlüssel bsteht aus zwei Tabellen. 256 Bytes Vertauschungs-Tabelles und 256 Bytes Subsitutions-Tabelle. Beide entalten wie geagt nur Bytes mit Wert 0.

Das 1.Datenbyte ist 0. Dient als Indexin Subsituionstabelle und an Index 0 steht dort 0. Aus dem Datenbyte 0 wird also Outputbyte 0. An Index 0 der Austauschtabelle steht 0, ergo wird im Output Datenblock 0 unser Outputbyte 0 eingetragen.

Nun wird der Addresszähler +1 inkrementiert.

Im 2. Datenbyte steht 0. Das ist Index in Subst-Tabelle. An Index 0 steht dort 0. Aus Datenbyte 0 wird Outputbyte 0 erzeugt. An Austasuchtabellemit Index 1 steht 0. Index 0 im Outputdatenblock bekommt das Outputbyte 0 gespeichert.

Ups hatten wir nicht eben schon das 1. Datenbyte substiuiert von 0 nach 0 und an Index 0 im Output gespeichert ?
Nun haben wir Datenbyte 2 == 0 ebenfalls zu 0 substituiert und an Index 0 im Outputpuffer gespeichert.

Wenn aber nun alle 256 Bytes der Daten aus 0 bestehen und unser 2*256 Bytes Passwort ebenfalls nur aus Nullen dann heist dies ja das unser Outputdatenblock immer nur das 1. Byte mit 0 berschreibt !

Eine sicherer Verschlüsselung zeichnet sich NICHT dadruch aus das man mit möglichst großen Passwörtern rein garnichts macht, sondern mit den notwenig großen Passwörtern das mathematisch, sprich kombinatisch sicherste ermöglicht. Das heist: die Bitröße eines Passwortes oder der Blockgroße des Ciphers definiert leider nicht dessen Sicherheit.

In deinem Fall gibt es im Set der 2^(512* mögloichen Schlüssel eine enorm große Menge von Schlüsseln die absolut keine Sicherheit bieten gescheige denn überhaupt funktionieren.

Ein halbwegs korrekter Schlüssel müsste aus 2 Blöcken bstehen a 256 Bytes und in jedem dieser Blöcke kämen die Zahlen 0 bis 255 nur einmalig vor. Aber auch dann wird der Schlüssel DIREKT im Algorithmus zu Transformation der Inputdaten benutzt. Damit enthalten die Outputdaten im Zuammenhand mit den bnekannten Inputdaten 1 zu 1 die Information welchen Schlüssel wir benutzt haben. Das muß unsicher sein. Gute verfahren schützen den Schlüssel indem sie diesen 1. mit einem KeySheduling schützen und 2. niemals damit direkt die Daten berarbeiten.

Gruß Hagen

Wie knacken wir den Schlüssel ?

1.) Wir wählen einen beliebigen Schlüssel.
2.) nun erzeugen wir eine Nachricht die aus 256 Datenblöcken a 256 Bytes besteht.
3.) der 1.Datenblock besteht aus den Zahlen 0 bis 255
4.) der 2. Datenblock bsteht aus den zahlen 255,0 bis 254
5.) der 3. Datenblock besteht aus den Zahlen 254,255,0bis 253

also jeder nachfolgende Datenblock wird um 1 Byte rotiert.

Aus der verschl. Nachrocht können wir 1 zu 1 das benutzte Passwort errechen.

Wie ? Das sollte der Autor des Verfahrens wohl selber rausfinden können

Immerhin ist es seine Aufgabe uns einen mathm. korrekten Beweis zu liefern das sein Verfahren auch wirklich sicher sein muß.

Übrigens: das Patentamt hat garnicht die Zeit noch das Knowhow ein patentiertes Verfahren zu verifizieren, das ist also garnicht dessen Aufgabe.

Gruß Hagen

@Hagen: Ich bin mir nicht ganz sicher, aber so wie ich das Verfahren verstehe, muss ein Schlüssel schon 2mal alle Bytes von 0 bis 255 enthalten. Ansonsten wäre der Substitutionsschritt sinnfrei, und die Permutation erst recht. Das wäre dann keine Verschlüsselung mehr, sondern nur noch ein Hashverfahren (wenn überhaupt).

Dass man aus Kenntnis von Klar- und Kryptotext den Schlüssel berechnen kann, habe ich ja auch schon versucht zu erklären. Imho muss man dafür nichtmal den Klartext vorher auswählen können (allerdings wird es dadurch einfacher )

Ich habe ehrlich gesagt schon daran gedacht, heute morgen mal bei meinem Krypto-Prof vorbeizusschauen, aber ich denke, das kann ich mir nach den letzten Postings sparen

btw.: meine Frage von oben steht noch: Was sind die ersten 520 Bytes in der verschlüsselten Datei?

Ich hatte gestern nur wenig Zeit (mein Akku war fast leer), also sorry für die blöden Tippfelher.

Die Sache ist doch so:

1.) auf Grund der WinWord Dateien kann man nur sehr schwer erkennen wie das Verfahren arbeitet, unprofessionell. Also nur mit viel Erfahrung und dem Wissen was es alles für Verfahren gibt hat man überhaupt eine Chance erahnen zu können worum es geht.

2.) als Demonstration eine Anwendung zu bauen die eben nicht 1 zu 1 nur das Verfahren demonstriert, sondern eben auch ein Preprocessing durchführt und in den Outputdateien auch noch Header speichert ist für eine Analyse sinnfrei.

3.) in den Outputdaten werden also noch Dateiinformationen gespeichert und sehr wahrscheinlich wird auch das Passwort noch umgewandelt.

4.) in diesem Verfahren wird es im Set aller möglichen Passwörter nur ehr sehr wenige geben die stärker snd als die vielen andernen Schlüssel. Ein Schlüssel aus lauter Nullen wäre zb. ein absolut schwacher Schlüssel. Ein Passwort das in beiden Hälften aus den Zahlen 0 bis 255 besteht wäre ein starkes Passwort. Man kann sich nun ausrechnen wieviele starke Schlüssel es gibt -> 256 * 256 * 2 Kombinationen aus dem Set von 256^256 * 2 Kombinationen. Das ist ein verschwindend geringer Prozentsatz. Sowas ist ein überzeugendes Indiz für eine sehr schwache Verschlüsselung.

5.) Es gibt ganz verschiedene Angriffe. Die Brute Force Attacke ist ein immer erflgreicher Angriff bei jedem heutigen Verfahren. Allerdings ist es auch der Angriff der die größte Komplexität besitzt und somit abhängig von der Komplexität des Verfahrens und der Schlüssel praktisch niemals durchführbar sein muß, eben damit das Verfahren als sicher gelten kann.

Es gibt aber auch andere Angriffsanrten, zb. Known Plaintext Attacks -> wir kennen die Daten die verschlsselt wrden und den Output -> Ciphertext kennen wir eh immmer. Oder die Chosen PlainText Attack -> wir können dem System sagen welche Daten zu verschlüsseln sind. Dies ist eine sehr effiziente Atacke im Vergleich zu den anderen. Exakt diesen Angriff habe ich oben benutzt. Und dann gibt es die differentielle Kryptoanalyse. Dieser Angriff ist immer dann effizient wenn man keine Blockverschlüsselung benutzt, keine Substitution mit SBoxen benutzt. Und exakt das ist auch eine Schachstelle im hier genannten Verfahren. Es nutzt tatsächlich keine SBox auch wenn die 256 Bytes der Substitutionstabelle im Passwort dies vermuten ließe. Denn eine SBox würde eben sicherstellen das bei Daten die aus lauter Nullen bestehen nicht der Output ebenfalls aus lauter Nuller bestehen kann. Sie würde auch indirekt sicherstellen das das Passwort eben NICHT direkt zur Datenmanipulation herangezogen wird und es somit keinen Angriff gibt, wie bei Cäsarciphern üblich, indem eine simple Haüfigkeitsanalyse ausreichen würde.

Insgesamt betrachtet:

die Dokumentation und Demonstration ist unzureichend. Der mathematische Beweis geht am Thema vorbei wenn er nur die Kardinaltät des Schlüsselraumes als Indiz für Sicherheit heranzieht und nicht auf die Kardinalität und die Unmöglichkeit einer Umkehrfunktion beweist.

Gruß Hagen