[HaBo]

Elderan

Anzeige

Hallo,
also ich wollte man einen einfachen Verschlüsselungsalgorhytmus bauen, leider treten hin und wieder Probleme auf. Jetzt habe ich die Ursache gefunden, aber hier das Prinzip des Algo.

Man hat einen Text und einen Key, die sich so "überlagern":
G a n z G e h e i m e r T e x t
K e y K e y K e y K e y K e y K


Jetzt werden die ASCII-Werte von den Buchstaben ermittelt, also G wird zu 71 und K zu 75. Diese beiden Werte werden jetzt Addiert (ergeben 146) und dann wieder in ein ASCII Zeichen umgewandelt, hier wäre es: '

Umgekehrt läuft es dann genauso ab, bloß der die Key Werte vom Textabgezogen werden.

Verschlüsselt sieht das ganz dann so aus: ??çzk??h°Î?e??Íe??

Das ist ink. Leerschritte

So mein Problem ist jetzt:
Das Leerzeichen hat den Wert 32 sowie 160. Wenn jetzt bei der Addition 160 rauskommt, steht dort ein Leerzeichen. Wenn ich das dann entschlüsseln möchte, denkt das Programm dann, es hätte den Wert 32 (für Leerzeichen). Die Key Zahl wird dann von der 32 abgezogen und man erhält ein ganz anderes Zeichen, als das was man verschlüsselt hat, denn am Anfang hat das Programm z.B. 110 (n) + 50 (2) = 160 gerechnet, und beim Entschlüssel rechnet es dann: 32 - 50 (2)=..).



Dies ist natürlich ärgerlich.

Kennt jemand eine Lösung? Also es würde mit Trennzeichen +Zahlen gehen, also ca. so:

100|160|80|90|170|160

Aber das sieht nicht besonders schön aus, kennt ihr evt. noch eine andere Lösung?

lestat

leider kann ich dir bei deinem problem nicht helfen

wie ich den algorythmus finde?
nun die idee ist ansich nicht schlecht, aber wenns wirklich ans eingemachte geht, tja dann ist er eigentlich MIES

der schlüssel wiederholt sich immer wieder, dadurch ist viel zu viel regelmäßigkeit drin. würde jetzt mal behaupten das er mathematisch zu leicht angreifbar ist, ebenso wie mit bruteforce. es reicht ja schon ein einziges segment des ganzen crypto textes zu entschlüsseln um ihn dann anschließend zum großteil wieder lesbar zu machen da sich wie schon gesagt der key immer wieder wiederholt.

außerdem ist ein solcher algorythmus sehr anfällig für häufigkeitsanalysen wordurch man auch relativ schnell und sicher wieder zum ergebniss komm.

z.b. ist in der deutschen sprache das E der häufigste buchstabe.
man analysiert jetzt einfach deine chiffrierten text auf das häufigste zeichen. dies ist dann mit einer gewissen warscheinlichkeit das E usw...
(einschlägige tabellen dazu sind auch recht schnell mit google gefunden)

einem wirklichen knackversuch hält dieser algorythmus wohl nicht lange stand
aber um die meisten abzuschrecken reicht er alle mal

die frage ist, wofür brauchst du das`?

es gibt doch eigentlich genug open source algorythmen die sehr sicher sind, oder gehts nur darum einfach mal selbst zu programieren?

wenn ja dann ist dies schonmal ein guter anfang!
google doch mal nach dem schema des DES algorythmus zum beispiel und kuck dir dann für den nächsten eigenbau da n paar teile ab

Elderan

Hallo,
also das "Programm" ist per PHP geschrieben und dient als Spielerrei, der Quellcode ist auch öffentlich.

Also ich hab mal versucht den Code zu brechen und ich muss sagen es war zu leicht, leider :/

Hab einen 1300 Zeichen langen Text mit einem zufälligen 100 Zeichen Key verschlüsselt.

Innerhalb 1 Sekunde konnte ich per PC den richtigen Key herrausfinden, naja dumm gelaufen.

Selbst per Hand ist das leicht

Denn man findet erst per Hand oder besser per PC herraus wielang das PW ist, das geht in unter 1 Sekunde per PC, dort zählt man die Überschneidungen oder so.
Klappt aber super mit dem herrausfinden ,)

Wenn der Key 10 Zeichen hat, schreibt man sich jeden 10. Buchstaben herraus, denn jeder 10. Buchstabe wird mit dem gleichen Key Buchstaben verschlüsselt.

Jetzt wandelt man die Buchstaben in den ASCII Wert um, und sucht sich die kleinste Zahl herraus. Der Leerschritt ist am häufigsten in einem Text (0,1% mehr als e oder so ) und hat auch eigentlich den kleinsten ASCII Wert in einem Text von 32.

Von der kleinsten Zahl zieht man dann 32 ab (ASCII Wert für Space), und schon hat man den 1. Buchstaben des Keys.
Dies macht man dann mit allen 10 stellen und schon hat man den Key, tja sowas ist ärgerlich.

Wenn man 5 Buchstaben des Keys schon hat, kann man meistens auch schon raten

Naja mal überlegen wie ich das sicherer hinbekomme

gmw

Es gibt einen derartigen Algorythmus bereits, aber noch ein wenig komplizierter. Die Ascii Nummern werden Binär ausgegeben (also 011001 blabla) und dann wird verglichen. Wenn an einer Stelle Text und Key 0 haben dann kommt 0 raus, bei 1 1 auch 0 und bei 0 1 oder 1 0 = 1 (das nennt sich ein XOR Operation)

Dannach wird wieder in ASCII Nummer und dann Text zurückverwandelt...

Auch dieser Algorythmus kann ohne Key rückberechnet werden, in dem man einfach nach Regelmäßigkeiten sucht...

Allerdings ist XOR unknackbar, wenn der Key genau gleich lang wie der Text ist (und es ist anzunehmen dass es nicht innerhalb weniger Wochen möglich ist einen derart langen Key zu knacken.

Du könntest also nun effektiv die Ascii zahlen mit Binärwerten machen, das sollte dein Problem mit dem Leerzeichen lösen...

Golgotha

Mach's noch anders.
Dein Alphabet, also Dein Zeichenvorrat steht in einer Tabelle:

dabei kann der Zeichenvorrat auch durcheinandergewürfelt sein.
Es sollten nur druckbare Zeichen in der Tabelle stehen, das Leerzeichen
darf AUF KEINEN FALL dabeisein. Warum?? Find es selbst heraus!

Dein Schlüssel ist dann eine Zahl, z.B:

Dein zu verschlüsselnder Text sei:

Nun wird der erste Buchstabe des zu verschlüsselnden Textes in der Tabelle
gesucht und um die erste Ziffer des Schlüssels weitergezählt.
Dabei wird die Tabelle modulo, also als Ringtabelle gesehen.
Dies wird mit allen weiteren Klartextbuchstaben und den entsprechenden
Schlüsselziffern gemacht:

Nun ist aus "warez" das Chiffrat "bgzng" geworden.

Der Deschiffrierer muss nun die Alphabetttabelle und die Schlüsselzahl kennen
und kann den selben Algo ausführen, zählt aber dann entsprechend der
Schlüsselzahl zurück.

und hat damit den Klartext wieder.

Golgotha.

__________________
Man sieht nur mit dem Herzen gut.
Wirklich relevante informationren sind für's Auge unsichtbar!

Elderan

Hallo,
gut das wäre eine Möglichkeit, würde auch nicht viel mehr Sicherheit mitbringen.

Der Nachteil ist aber, das mal solche Text nur sehr schwer lesen kann, wenn alles klein bzw. alles Groß geschrieben wurde und zusammen.

Aber ich hab es jetzt so gemacht, würde gerne wissen, wie es mit der Sicherheit steht. Ob man dafür nur 1 Sekunde braucht wie vorher, oder doch schon etwas länger.

Also hier der Algorithmus:

Der Text wird zuerst wieder in die ASCII Zahlen umgewandelt.
G wird zu 71 und K zu 75. Danach wird von den Zahlen (71 und 75) der Binär-Wert herrausgefunden, also 71 = 1000111 und 75 = 1001011.

Jetzt werden (nur beim Text, nicht beim Key) die Zahlen vorne mit Zahlen aufgefüllt, bis sie eine Länge von 8 haben, also aus 1000111 => 01000111.
Das musste ich wegen dem späterem Entschlüssel so machen

Das gleiche passiert mit dem Key, bloß ohne das Aufüllen (also auch erst ASCII Wert und dann Binärwert). Danach wird durch wiederholung der Key genauso lang gemacht wie der Klartext, sprich:
KeyKeyKeyKey (das bloß als Binärwert)

Jetzt wird per XOR der Klartext mit dem Key Verschlüsselt.
Wenn man G mit K verschlüsselt, sieht das Resultat so aus:
G: 01000111
K (+1 K-Bit): 1001011 1

XOR:
01000111
10010111
=
11010000


Das ist dann auch die Ausgabe.

Wie sicher ist das Verfahren?


Edit
Hallo,
also ich füll mit 0'len vorne auf.

Also wenn dort steht:
01100110 (Text)

Der Key wird nich aufgefüllt:
Also z.B.
1100110

Naja habs mitlerweise selbst geknackt. Denn durch dieses auffüllen, schreibt man sich jetzt jedes (Länge des Key's)-Zeichen herraus.

Dieses Zeichen wandelt man in Binär Code um.
Wenn die Zahl 6 stellen oder weniger hat, so ist es eine 0 im Key, wenn nicht ist es eine 1.
Sprich alle Zahlen die größer als 128 (oder 127 als einzigste Ausnahme ?? ) sind im Key eine 1, die kleiner sind eine 0

Wenn man jetzt 7 Zahlen zusammen hat (manchmal , so hat man den 1 Buchstaben.

Als Beispiel:
Key: a => ASCII-Zeichen: 97 => Binär: 1100001
Text: 162#230#111#125#89#17#128
....

162: => 1
230: => 1
110: => 0
125: => 0
89: => 0
17: => 0
128: =>1

Schon hat man den 1. Buchstaben des Keys.

Aber würde evt. eine hin und rückrunde das Verfahren sicherer machen.

Und zwar so
G: 01000111
K (+1 K-Bit): 1001011 1

XOR:
01000111 <= Text
10010111 <= Key
=
11010000 <= Zwischenergebnis

Jetzt die Rückrunde
11010000 <= Text
11101001 <= Key
=
00111001 <= Gesamt

cromatic

Erklär mir mal wie man von 160 auf 32 kommt.
Vielleicht liegt ja da schon das Problem ...

cromatic

Golgotha

@cromatic:

In der Kryptografie wird mit "Restklseen" also modulo gerechnet.

Stell' Dir 'ne Analoguhr vor. Wie ist dann das Zifferblatt aufgebaut?
Richtig, der "Zahlenraum" geht "im Kreis" von 12 - 12 Uhr also.
Wir fallen beim Berechnen einer bestimmten Uhrzeit nicht aus dem geschlossenen
Kreis heraus.
Nun haben wir jetzt 11 Uhr. Addiere jetzt zur Uhrzeit 4 Stunden.
Was würde die Uhr anzeigen? Jupp! 3 Uhr! Es wird als nicht mit den
errechneten Zahlen, sondern mit den Resten gerechnet


in unserenm Zahlenraum ist 11+4=3 (der Rest von 13) .
Wenn ich jetzt von meiner 3Uhr 4 Stunden abziehe, zeigt der Zeiger wieder
auf 11 Uhr,
3-4 =11
Ist's jetzt klar?


Golgotha

__________________
Man sieht nur mit dem Herzen gut.
Wirklich relevante informationren sind für's Auge unsichtbar!

FIA|n00ne

Hi,

zu der ursprünglichen Frage:

Prüfe bei jedem Schritt, ob der Ascii -Wert, der errechnet wird 0 oder kleiner ist. Falls ja, dann kannst du davon ausgehen, dass der Ausgangswert nicht 32, sondern 160 war.
Das läßt sich so einfach sagen, da der Schlüssel keinen Ascii-Wert unter 32 enthalten kann, da diese alle Steuerzeichen sind.

Im schlimmsten Fall ist der Schlüssel-Wert 32 (Leerzeichen) und wird von 32 (eigentlich 160) abgezogen. Somit ist das Ergebnis 0 und du weisst bescheid. Sollte der Schlüsselwert höher sein (bsp: "a" = 65 (?)), dann ist das Ergebnis immer kleiner 0 und du weisst ebenfalls bescheid.

Allerdings sollte man diese (Not-)lösung nur verwenden, wenn keine anderen Probleme auftreten, da sonst das Ergebnis, das kleiner 0 ist auch auf eine andere Wiese erzeugt werden könnte.


Ich hoffe, ich konnte helfen.



n00ne

Elderan

Also wenn der Buchstabe n mit dem Key 2 verschlüsselt wird, so ergibt die Summe davon 160.

Diese 160 wird in einen Leerschritt umgewandelt.

Bei der Entschlüsselung denkt aber der Interpreter dieser Leerschritt hatt die ASCII Nummer 32 und zieht dann davon 50 ab, und somit erhält man nicht den Klartextbuchstaben n

Also das Problem ist, das ein Leerschritt die Werte 32,160 und 173 haben kann

Momentan gebe ich die ASCII Zahlen aus

cromatic

Warum benutzt Du dann ein solches Zeichen, was keine eindeutige Abbildung hat ?
Das ist mathematisch auch nicht sehr toll. Vergleichbar mit der Wurzelfunktion. Nur das man hier sogar 3 Werte hat.
Vielleicht solltest Du Dir ein Zeichen davor setzen, was den Wert des Leerschritts genauer spezifiziert. Bläht Deine Daten zwar auf, aber gibt Dir die Möglichkeit der eindeutigen Identifizierung ...

cromatic