BITTE hilfe! erster byte wird falsh entschlüsselt

lustig

lk schrieb:

Nein, das erste zeichen ist immer noch falsh. Und auf den Diagonalen können rgendwelche werte liegen, die auch X-mal vorkommen.

Das heisst, dass die Verschluesselung des ersten Zeichens nicht wirklich funktioniert (nicht umkehrbar ist). Extrembeispiel: Alles 1 auf der Diagonale. Das erste Zeichen wird immer 1 sein, unabhaengig davon was du verschluesselst.
Setze doch einfach in[-1] auf irgendetwas bekanntes, z.B. 'A'. Dann machst du:

char startingValue='A';
out[0]=tab[in[0]][startingValue];

Das sollte das Problem loesen. Wenn ich mal Zeit habe, versuche ich mich auch an dem verschluesselten Text :).

lk

SeppJ, giebt es denn auch andere methoden, zb verschlüsselte Binärdateien ohne die tabelle zu entschlüsseln? Wenn ja, könntest du die sagen ? (Wenn nein, reicht es aus die bits to verschieben, oder?)

SeppJ

lk schrieb:

SeppJ, giebt es denn auch andere methoden, zb verschlüsselte Binärdateien ohne die tabelle zu entschlüsseln? Wenn ja, könntest du die sagen ? (Wenn nein, reicht es aus die bits to verschieben, oder?)

Ich verstehe die Frage nicht. Meinst du, ob es möglich ist, auch Dateien zu entschlüsseln, die keine menschliche Sprache enthalten? Ja, sofern man eine ungefähre Vorstellung vom Inhalt hat. Es gibt immer Muster.

Und hier noch ein anderer Ansatz:
Dein Schlüssel hat höchstens 255*255*255 Kombinationen, das sind ungefähr 16 Millionen. Davon sind sehr viele nicht gültig, weil nur solche gelten, die ein korrektes Sudoku-Muster haben. Aber selbst wenn man es mit 16 Millionen Kombinationen zu tun hat: Ein kleiner Heimrechner kann 16 Millionen Schlüssel in einigen Minuten bis wenigen Stunden durchprobieren, je nach Geschwindigkeit und Länge des Textes. Ich könnte mir vorstellen, deinen Text mit solch einem Verfahren zu knacken, falls sich die Wortraterei als zu mühsam erweisen sollte.

lk

Nein. Du würdest es ja nach der anzahl der buchstaben oder so machen, aber wenn es kein text wäre, sondern eine binärdatei, dann würde dies ja nicht wirklich funktionieren. Würde es auch ausreichen - bei normalen texten - die bits jeweils for der verschlüsselung zu verschieben ? Daduch würde dann der text verwischt, und aus den danach verschlüsselten daten könnte man nicht mehr die anzahl der buchstaben bestimmen.
`

1 2 3 4 5 6 7 8

2 3 4 5 6 7 8 1

3 4 5 6 7 8 1 2

4 5 6 7 8 1 2 3

5 6 7 8 1 2 3 4

6 7 8 1 2 3 4 5

7 8 1 2 3 4 5 6

8 1 2 3 4 5 6 7

`

Hast du noch Ideen, wie man dies entschlüsseln könnte ? (ich nehme mich mal heute oder morgen an dieses bit-shifting)

lustig

SeppJ schrieb:

Dein Schlüssel hat höchstens 255*255*255 Kombinationen, das sind ungefähr 16 Millionen.

Hmm, da ist dir aber ein kleiner (*hust*) Fehler unterlaufen. Eigentlich waere es
(256*256)^256. Eine etwas kleinere Abschaetzung waere 256!*256, was immer noch ca. groesser als 10^500 ist...

SeppJ

lk schrieb:

Würde es auch ausreichen - bei normalen texten - die bits jeweils for der verschlüsselung zu verschieben ? Daduch würde dann der text verwischt, und aus den danach verschlüsselten daten könnte man nicht mehr die anzahl der buchstaben bestimmen.

Ich verstehe nicht, wo der Unterschied sein soll, wenn du alles bloß verschiebst.

Hast du noch Ideen, wie man dies entschlüsseln könnte ?

Selbst wenn ich einsähe inwiefern mein anderer Ansatz nicht funktionieren sollte: Ich bin nicht einmal ansatzweise ein Kenner von Entschlüsselungsverfahren. Ich habe einfach nur den Thread gelesen und mir gedacht "Da fällt ja selbst mir ein Angriff ein" und habe Spaß daran, das Verfahren in der Praxis zu überprüfen. Wenn ich mich mit Kryptographie auskennen würde, wäre ich in der Lage die konzeptionellen Schwächen zu erkennen und gezielt auszunutzen. Wahrscheinlich würde sogar ein sehr viel kürzerer Text ausreichen als der den du hochgeladen hast.
Das es konzeptionelle Schwächen des Verfahrens geben muss ist klar, da du kein mathematisches Konzept vorweisen kannst, warum das Verfahren etwas taugen sollte. Dass du zufällig etwas brauchbares gefunden haben solltest, ist sehr sehr unwahrscheinlich. Kryptographie denkt man sich nicht mal eben aus, Kryptographie entwickelt man.

lustig schrieb:

SeppJ schrieb:

Dein Schlüssel hat höchstens 255*255*255 Kombinationen, das sind ungefähr 16 Millionen.

Hmm, da ist dir aber ein kleiner (*hust*) Fehler unterlaufen. Eigentlich waere es
(256*256)^256. Eine etwas kleinere Abschaetzung waere 256!*256, was immer noch ca. groesser als 10^500 ist...

Ups, hast natürlich Recht. Also Brute-Force ist wohl doch nichts.

lk

SeppJ schrieb:

lk schrieb:

Würde es auch ausreichen - bei normalen texten - die bits jeweils for der verschlüsselung zu verschieben ? Daduch würde dann der text verwischt, und aus den danach verschlüsselten daten könnte man nicht mehr die anzahl der buchstaben bestimmen.

Ich verstehe nicht, wo der Unterschied sein soll, wenn du alles bloß verschiebst.

Wenn ich die daten vor dem verschlüsseln mit einer immer-gleichen methode verändere, die daten dann aber verschlüssele, kann man die immer-gleiche veränderung nicht vor dem entschlüsseln rückgängig machen. Somit kann man auch nicht auf die Buchstaben kommen, oder so. Auf jeden Fall aber würde das cracking-Verfahren von dir wegfallen (ein Schritt in der 'Kryptographie-Entwicklung' :p ).

(Kennt jemand vielleicht jemanden, der sich mit so etwas auskennt, und helfen könnte?)

SeppJ

lk schrieb:

Wenn ich die daten vor dem verschlüsseln mit einer immer-gleichen methode verändere, die daten dann aber verschlüssele, kann man die immer-gleiche veränderung nicht vor dem entschlüsseln rückgängig machen. Somit kann man auch nicht auf die Buchstaben kommen, oder so. Auf jeden Fall aber würde das cracking-Verfahren von dir wegfallen (ein Schritt in der 'Kryptographie-Entwicklung' :p ).

Eine monoalphabetische Veränderung bringt gar nichts.

(Kennt jemand vielleicht jemanden, der sich mit so etwas auskennt, und helfen könnte?)

Wenn dir jemand reicht, der sich ein paar Stunden mit dem Thema auseinandergesetzt hat: Mitlerweile ich.
Also: Was hast du vor?

lk

Also, ich will natürlich den Algorythmus sicher machen, gegen diese ganzen angriffs-Methoden. Ich habe vor, immer jeweils eine angriffs-Methode herauszufinden, und den Algorythmus entsprechend umändern, sodass er sicher gegen sie ist. Leider habe ich nicht viel Ahnung auf diesem Gebiet, aber man lernt ja das ganze Leben durch...

DocShoe

Wenn du schon einen eigenen Verschlüsselungsalgorithmus bauen willst (warum kannst/darfst du keinen fertigen benutzen?) kannst du dir auf dieser Seite mal einen anschauen, der sowohl sicher als auch einfach zu implementieren ist:

Solitaire

SeppJ

Ok, ich habe mich in den letzten Tagen mal ein bisschen mit Kryptoanalyse beschäftigt und kann dir sagen, was an deinem Verfahren nicht stimmt:

Dein Verfahren ist knackbar durch Frequenzanalyse, wie ich demonstriert habe (auch wenn ich nicht den Nerv habe das wirklich bis zum Ende durchzuziehen). Das ist eine prinzipielle Schwäche deines Verfahrens, da es sich um ein ersetzungsverfahren mit einer begrenzten Zahl an Alphabeten handelt. Es ist bekannt, welches Alphabet für welches Zeichen verwendet wurde, denn das vorherige Zeichen bestimmt das ALphabet. Dadurch ist es knackbar mit einer Frequnzanalyse, nur dass man es mit einer großen Zahl an Alphabeten zu tun hat.

Was könntest du dagegen tun? Mach die Wahl des Alphabets nicht vom vorherigen Zeichen, sondern von einem anderen Schlüsselwort abhängig.

Problem: Auch dieser Trick ist alt bekannt und längst analysiert: Man berechnet dann den Koinzidenzindex und kann so die Schlüssellänge erraten. Dann hat man es wieder mit einer bekannten Zahl an Alphabeten zu tun und kann auf diesen wieder eine Frequenzanalyse machen.

Was man dagegen tun könnte, ohne dein Verfahren grundlegend umzukrempeln, weiß ich nicht. Man kann es natürlich immer eine Stufe komplizierter werden lassen ,indem du den Schlüssel noch alternieren lässt, aber das ist keine prinzipielle Lösung und vergrößert nur die Zahl der Nachrichten, die ein Angreifer mitlesen muss, bevor er den Code angreifen kann.

Eine weitere Schwäche: Fallt dem Angreifer eine verschlüsselte Nachricht in die Hände, deren Quelltext er kennt, kann er ganz einfach den Schlüssel berechnen und somit alle anderen Nachrichten entschlüsseln, die mit dem gleichen Schlüssel verschlüsselt wurden. Selbst wenn man nur Teile der Nachricht kennt (z.B. es geht mit einer Anrede los, oder endet mit dem Wetterbericht), kann man schon einiges an Aussagen über den Schlüssel machen. Wenn man dann einige Teile des Schlüssels sicher kennt, kann man den Rest erraten. Auch dies ist eine prinzipielle Schwäche, die nicht durch einfache Abänderung des Verfahrens behoben werden kann.

Der Schlüsselaustausch ist eine weitere Schwachstelle. Der Schlüssel muss irgendwie von A nach B gelangen und darf dabei nicht abgehört werden. Dies ist eine prinzipielle Schwäche aller symmetrischen Verschlüsselungsverfahren. Dagegen helfen asymmetrische Verfahren (zumindest zum Austausch des Schlüssels), die grundsätzlich anders funktionieren als dein Verfahren.

lk

Also, über die Asymetrischen Verschlüsselungsmethoden habe ich mich auch schon informiert, leider habe ich nirgends etwas gefunden wie die dinger funktionieren.
Wenn ihr meint, das Verfahren sei nicht mehr zu retten, werde ich's an etwas anderem versuchen, was aber schade wäre...
Danke dir, SeppJ, dass du mir so fiel geholfen hast

SeppJ

Für asymmetrische Verfahren ist die Idee, dass man sich ein mathematisches Problem sucht, dass in einer Richtung sehr einfach ist und in der Umkehrung sehr schwierig. Darauf baut man dann ein einfaches Chiffre auf. Da man Mathematiker sein muss, um über sowas den Überblick zu haben, ist es nicht leicht, selber so ein Verfahren zu entwickeln.

Schau dir für ein sehr gebräuchliches Beispiel mal RSA an. Dieses basiert auf zwei mathematischen Problemen. Erstens die Leichtigkeit zwei Primzahlen zu finden und zu multiplizieren, aber die Schwierigkeit eine Zahl in zwei Primfaktoren zu zerlegen. Zweitens die Schwierigkeit die Eulerfunktion einer Zahl ohne Kenntnis von deren Primfaktoren zu berechnen.

Da asymmetrische verfahren recht Rechenaufwändig sind, wird häufig nur ein Schlüssel für ein Blockchiffre damit übertragen. Du kannst dir ja auch mal die gängigen Blockchiffres angucken. Diese sind (relativ) sicher, sofern man den Schlüssel sicher übertragen kann. Für simple Blockchiffres gibt es Angriffe, die neueren sind noch nicht genau erforscht, gelten aber (bisher) als sicher. Die moderneren Verfahren sind aber teilweise nicht ganz einfach zu implementieren.

Ich würde für den Anfang mal das schon vorgeschlagene Solitaire als Hauptchiffre implementieren und RSA als Übertragungsweg für den Schlüssel. Beide sind relativ einfach umzusetzen (zumindest wenn du für RSA eine Bibliothek für große Zahlen benutzt). Und das ist dann schon so sicher, dass es sich eher lohnt, einen unkonventionellen Angriff (also Überredung, Wanzen, Erpressung, Folter) zu starten, anstatt sich an dem Verschlüsselungsverfahren selbst die Zähne auszubeißen.

lk

Wie wär's mit Pi? Man müsste zB die anzahl der danachkommenden stellen kennen, die zur verschlüsselung verwendet wurden. Wenn mann sie nicht kennt, so geht wegen der minimalen unterschiede die berechnung falsh. (checksum von Pi aus dem Speicher generieren, und damit verschlüsseln). Leider wurden bisher nur 200 Milionen nachkommastellen entdeckt, was das verfahren für brute-force sehr anfällig macht. Das könnte man aber mit zusätzlichen parametern beheben (noch kA mit welchen). Oder man könnte eben etwas wählen, was man bis zur unendlichkeit weiterführen kann, zB Fibonacci: 1 1 2 3 5 8 13 21 34 55 89...

Verschlüsselung:
-> Pi-nachkommastellenanzahl wählen.
-> Pi-Checksum generieren
-> mit der checksum verschlüsseln

Entschlüsselung:
-> Pi-Checksum generiren (Angreifer würden hierran scheitern, weil wenn die zahl auch minimal falsh ist, so ist )
-> Entschlüsseln

SeppJ

Pi kennnt jeder, kann jeder berechnen.

volkard

lk schrieb:

Wie wär's mit Pi? Man müsste zB die anzahl der danachkommenden stellen kennen, die zur verschlüsselung verwendet wurden. Wenn mann sie nicht kennt, so geht wegen der minimalen unterschiede die berechnung falsh. (checksum von Pi aus dem Speicher generieren, und damit verschlüsseln). Leider wurden bisher nur 200 Millionen nachkommastellen entdeckt, was das verfahren für brute-force sehr anfällig macht.

Wo lebst Du denn? Mach mal 2 Billionen draus.

lk

Okay, aber es würde trotzdem irgendein hash-wert ausreichen (zudem vielleicht auch noch varabler Länge).
Das heist leider noch nicht, dass der Algorythm sicher ist, denn es giebt dazu noch keinen...

volkard schrieb:

Wo lebst Du denn? Mach mal 2 Billionen draus.

Woraus? Meinst du es wurden bereits 2 Billionen nachkommastellen von Pi entdeckt ?

SeppJ

lk schrieb:

volkard schrieb:

Wo lebst Du denn? Mach mal 2 Billionen draus.

Woraus? Meinst du es wurden bereits 2 Billionen nachkommastellen von Pi entdeckt ?

Man kennt heute 2,7 Billionen Stellen.

hustbaer

lk schrieb:

volkard schrieb:

Wo lebst Du denn? Mach mal 2 Billionen draus.

Woraus? Meinst du es wurden bereits 2 Billionen nachkommastellen von Pi entdeckt ?

Entdeckt, hihi.
Man muss die nicht suchen, man muss die bloss ausrechnen

lk

Hmm, giebt es also schon eine feste Formel, mit der man beliebig viele stellen ausrechnen kann ?