[HaBo]

as3jg

Anzeige

Hallo Leute,

ich habe mir ein kleines Programm überlegt, welches Daten durch mischen verunstaltet. Die Frage ist nun, ist so etwas überhaupt sicher oder knackt das jedes Script-Kiddy notfalls mit Papier und Bleistift?

Das Programm funktioniert wie folgt:

Ein möglichst langes Passwort wird eingegeben (lernt schon mal wieder Gedichte auswendig ;-)

Aufgrund der Buchstaben des Passwortes werden über 40 verschiedene simple Algorithmen nacheinander aufgerufen. Insgesamt werden um die 1000 Algorithmen nacheinander angewand, also von den über 40 jeder mindestens einmal oder mehrmals.

Die Algorithmen sind:

o Vertauschen von verschiedenen Bits in zwei aufeinanderfolgenden Bytes

o Segmentweises umdrehen der Reihenfolge von Bytes, z.B. 37 Bytes einlesen, von vorne nach hinten umschaufeln und ausgeben und das für die gesamte Eingabedatei.

o Codieren von allen oder nur bestimmten Bytegruppen durch interne Codierungstabellen, also z.B. aus 3 mach 47, aus 47 mach 3, etc..

o Aufaddieren von fortlaufenden Zahlen auf die Bytefolge der Datei, abhängig vom Passwort.

Das dürfte die Bits ganz gut durcheinander wirbeln...

Hier ein Beispiel, was dabei rauskommt. Die Eingabedatei enthält 256xNULL (x'00').

0000 0000 31 96 F3 AC 99 BC DA FD 4D F8 63 9C 8E FD 5E 9F
0001 0001 44 2C 8F EB B5 17 B0 75 40 25 0D 20 46 05 B5 92
0002 0002 80 70 14 6C D5 05 EC 64 7D FF FF 84 B2 9B F8 41
0003 0003 96 59 58 E7 38 17 40 FD 2D BC 44 6D 7C 82 45 FE
0004 0004 2E D5 0B 9F 6F AF 40 08 B8 1D 88 B8 82 90 77 24
0005 0005 B5 37 5E 48 A8 CD 4F C9 15 31 6F 1E F4 88 44 72
0006 0006 52 9C 12 5E 12 21 F8 C7 E4 C9 AF 18 3C A1 9E FC
0007 0007 96 01 77 D2 8B 96 90 71 CC A2 E4 23 A5 99 31 0A
0008 0008 0D 35 B2 BC 68 DB 79 03 C4 05 16 88 86 51 A2 68
0009 0009 42 9B 72 7F E7 C0 B1 45 4F 59 0F 24 A2 A8 8B D5
0010 000A F3 61 D0 23 63 2C 59 C5 A6 C9 4D B3 48 B6 85 F7
0011 000B CD 57 F7 14 4C 5F 88 2F 6F 89 89 1F 65 E6 AE A2
0012 000C FC D9 A6 84 B7 60 82 BC 9D C2 14 AA BE CE B8 9D
0013 000D 53 3F 42 9F CA A2 62 C2 67 AE F5 1B D0 26 65 E7
0014 000E 2A 24 AA 7C F0 D9 42 FC 02 53 9D 8A E3 A6 08 DB
0015 000F 3B 5C DE F3 48 77 D4 8E 12 C4 28 45 82 E3 C9 D4

Das Passwort dazu lautet
"And Is It All We See And Seem, Just A Dream Within a Dream?"

Hier noch was zum üben, für die, die jetzt Blut geleckt haben:

0000 0000 A0 A7 05 E4 C6 FF F3 96 88 67 43 28 C6 68 75 8F
0001 0001 EB 3A 08 C7 A5 2B C9 5C CC BC A4 B0 86 4B C9 96
0002 0002 55 7D FA F3 BB 33 1F A9 37 2F 16 69

Das ist ein Titel eines Liedes, also ASCII-Text.

Also, würdet ihr einem solchen Programm eure Bankverbindung und Geheimzahl anvertrauen?

Gibt es Programme, die so etwas mit Brute Force evtl. knacken können?

Danke im Voraus und viel Spaß!

as3jg

softrunner

Auf den ersten Blick kommt mir das ganze schon recht sicher vor aber um das genauer zu beurteilen müsste ich mal ne Weile darüber brüten und die Algorythmen genauer unter die Lupe nehmen.
Falls du das Progamm wirklich schreiben wirst, dann schick mir doch mal ne PM. Unter Sicherheit beim Verschlüsseln verstehe ich immer sicher auch bei Inkenntisnahme des Sourcecodes. Vielleicht hast du ja mal Lust mir den Sourcecode zu schicken.


mfG, Softrunner

as3jg

Moin,

das Programm ist fast fertig, kann jetzt auch über 70 verschiedene Algorithmen. Leider ist noch ein Bock drinne, ich habe ein paar Fälle, wo er nicht zurück entschlüsseln kann.

Die Algorithmen sind alle simpel, z.B.:

o Lese N Bytes ein, drehe die Reihenfolge um und schreibe N Bytes raus.

o Lese 2 Bytes ein, vertausche zwei Bits und schreibe 2 Bytes raus.

o Lese 1 Byte ein, addiere eine Zufallszahl aus einem eigenen Zufallszahlengenerator und schreibe 1 Byte raus.

etc.pp.

Wenn's läuft, werde ich es unter http://freshmeat.net/ veröffentlichen. Meine Idee geht ja davon aus, daß das ganze öffentlich zugänglich ist und trotzdem sicher ist.

Und eben nicht so, wie die gängigen Verfahren a' la PGP etc., die eh in ein paar Tagen/Wochen/Monaten/Jahren durch ansteigende Rechnerleistungen geknackt werden können.

Gulliver

Deine Mühe in allen Ehren.

Aber Grundsätzlich gilt: ist dein verschlüsselter Text durch eine direkte
Umkehrung des Algorithmus wieder zu ENT-schlüsseln, ist das Verfahren
höchstens nur 2. Wahl.
Und den Weg möglichst viele Algos zu verschachteln sind schon andere gegangen, erfolglos.

Den Sourcecode, bzw. die Algos MUSST du offenlegen, wenn jemand
ein solchen Verfahren ernst nehmen soll.

Und was PGP angeht, sicher steigt die Rechnerkapazitaet um die Schlüssel
zu bruteforcen, allerdings auch um viel grössere Schlüssel zu erstellen.

Eulers Erbe ist das einzige bisher, welches vom reinen Algorithmus her nicht
befriedigened angreifbar ist.
Vielleicht postest du mal deine codes oder eine ausarbeitung der Algos;
hier wird dir sicher jemand helfen können.

as3jg

Moin,

es läuft jetzt anscheinend fehlerfrei.

Hier http://mitglied.lycos.de/joerggrohne/mixit1.0.tar.gz gibt's den Source,
ist auch ein Testtool und ein primitiver Codebrecher dabei.

Viel Spaß beim ausprobieren!

as3jg

Moin,

@Gulliver
>>Und was PGP angeht, sicher steigt die
>>Rechnerkapazitaet um die Schlüssel
>>zu bruteforcen, allerdings auch um viel grössere
>>Schlüssel zu erstellen.
Recht hast du, allerdings sind davon alte, verschlüsselte Daten nicht betroffen. Wenn jemand von deiner Platte eine Datei klaut und die in einem Jahr mit verbesserter Hardware knacken kann, kommt er trotzdem an die Daten, z.b. deine noch immer existente Bankverbindung und Geheimzahl, ran.

Mein Gedankengang, als ich über so etwas nachdachte, war u.a. folgender:

1. Wenn ich ein kodiertes File habe, kann ich daran erkennen, was es ist. Sei es über die Endung oder über einen Hex-Dump sehe ich einen Header. Damit kenne ich den Algorithmus und kann ihn mit Brute Force knacken. Zeit spielt keine Rolle (sage ich mal so, um zu beweisen, daß dieser Algorithmus knackbar ist).

2. Wenn ich weiß, was ich suche, kann ich solange alle möglichen Algorithmen anwenden, bis ich genau das Ergebnis gefunden habe. Z.B.: Wenn ich weiß, daß Osama ein arabisches Word benutzt, kann ich so lange entschlüsseln, bis ich ein arabisches Word-Dokument gefunden habe.

aber:

1. Wenn ich nicht weiß, WAS es ist, weil es keinen Suffix oder keinen Header hat, wo will ich ansetzen und knacken? Die Ausgabe meines Programmes hat keine Struktur und keinen Header. O.K., jeder, der hier mitliest, weiß jetzt, worum es geht, aber es erzeugt nur binären Mist. Und wenn der böse Schorsch W. mir ein solches File klaut, wie will er es knacken? O.K., der liest dann wohl auch mit ;-)

2. Wonach suche ich? Was wurde verschlüsselt? So einfach, wie damals bei Enigma ist es ja nicht, daß nur klar lesbarer deutscher Text rauskommen muß. Was ist, wenn die Eingabedatei ein JPEG, welches mittels Steganografie geändert wurde ist? Oder eine Bitmap, welche ein Foto der Daten ist? Oder ein Zip-Archiv? Oder irgend was ganz anderes?

Ein Algorithmus, der entschlüsseln will, muß wissen, wann er aufhören soll. Oder, er erzeugt Gigabytes von Mist, die ein Mensch sich ansehen und bewerten muß. Natürlich, rein mathematisch wird an Euler keiner vorbeikommen, (obwohl ich nicht genau weiß, was das bedeutet, außer es ist nicht so einfach rückwärts zu entschlüsseln), aber es geht um die Praxis. Man muß wissen, wonach man sucht, weil, wo will man denn sonst aufhören, zu suchen?

Ich glaube, daß man durch reines "Verstecken" und "Verheimlichen" erheblich besser Daten schützen kann, als durch "angeblich" sichere mathematische Verfahren.

Was meint ihr dazu?

P.S.: Ich glaube nicht, die absolute Lösung mit meinem Programm gefunden zu haben. Ich wollte bloß mal ein bißchen über das Thema reden. Also nicht zu ideologisch nehmen ;-)

LordCyrix

@as3jg,

es ist definitiv falsch zu glauben dass verstecken sicherer ist als mathematisches Verschlüsseln. Andererseits ist es auch falsch zu glauben, dass nur mathematisches Verschlüsseln allein ausreicht. Am besten fährt man immer noch, wenn man beides zusammen macht. Also zuerst mathematisch verschlüsseln und anschliessend den verschlüsselten Kram verstecken.
Im Übrigen muss eine Verschlüsselung immer nur so stark sein, wie der Zeitwert den sie überdauern soll. Das heisst wenn Du Daten hast, von denen Du weisst das sie nur 80 Jahre lang sicher verschlüsselt bleiben sollen, dann reicht eine Verschlüsselung die z.B. 100 Jahre den besten Rechenmaschinen standhält völlig aus. Ausnahme ist hier natürlich der Kollege Zufall der aber immer mit spielt, wenn auch mit geringer Wahrscheinlichkeit.

Zu der Sache mit der mathematischen Verschlüsselung. Es gibt eine Möglichkeit einen Algorithmus mit Hilfe von Modulo-Funktionen zu erzeugen, bei dem man keine eindeutige Umkehrfunktion bilden kann und es damit lediglich möglich wäre, per Brute-Force an diese Sache heranzugehen. Und Brute-Force ist ja bekanntlich die ineffizienteste Methode eine Verschlüsselung zu knacken.
Bei dieser bis heute recht sicheren Funktion handelt es sich um die Diffie-Hellman-Einwegfunktion.
Ich habe dazu mal einen Vortrag an der Uni ausarbeiten müssen. Dort habe ich das genau beschrieben wie das mit dieser Funktion funzt. Das entscheidende dabei ist dass Du Dir für den Wert y und p eine möglichst hohe Zahl (Primzahl) generierst und das dürfte kein grosses Problem sein. Schau einfach mal unter diesem Link nach. Denn je höher dein Wert y und dein Wert p sind, desto mehr Möglichkeiten einer Umkehrfunktion gibt es, so dass das ganze bei einer angemessen grossen Zahl ins Unermessliche steigt.

Zum Vergleich mal folgendes:

Eine umkehrbare Funktion wäre z.B. z=3^x
Die Umkehrfunktion zu z=3^x wäre dann x=log z zur Basis 3.

Eine Einwegfunktion ist die hier: z=3^x(mod 7)

hier gäbe es mehrere Umkehrfunktionen mit Hilfe des Modulo-Operators, und man müsste erst jede ausprobieren um das richtige Ergebnis zu erhalten. Je höher der Modulo-Wert ist, desto mehr mögliche Umkehrfunktionen gibt es, von denen jedoch nur eine die richtige ist.

Zur Erklärung was Modulo überhaupt ist einfach auf folgenden Link gehen.

Ich habe dort übrigens auch etwas zur Last-First-Problematik geschrieben, das dürfte vielleicht auch noch mal im Bezug auf Dein Vorhaben mit der Verwendung von mehreren Verschlüsselungsalgorithmen aufeinanderfolgend von Interesse sein. Weil es dann spätestens bei einer Verwendung eines Public Key zu Komplikationen kommen kann. Siehe hier .

Übrigens kann Deine Methode auch schief gehen. Nämlich genau dann, wenn Du ASCII-Zeichen verwendest, die nur in Deinem ASCII-Zeichensatz vorkommen, aber nicht im ASCII-Zeichensatz des Rechners von demjenigen der wieder Entschlüsseln will. Das ist ein wichtiger Punkt im Bezug zu Plattformunabhängigkeit. Eine Sparc-Workstation mit Solaris hat zum Beispiel einen anderen ASCII-Satz als ein normaler PC mit Windows.

Ich finds aber gut, dass sich jemand so viel Gedanken über Sicherheit von Daten macht. Naja, wer was zu verbergen hat der macht sich auch schonmal Umstände nicht wahr? ;D

as3jg

@LordCyrix
Knapp vorbei mit den Zeichensätzen, die sind auf beiden Maschinen gleich. Allerdings geht der ASCII-Zeichensatz nur von 0-127. Danach kommen dann die systemunterschiedlichen Zeichen, z.B. Umlaute. Das Elend kenn ich zur Genüge ;-) Das ist bei meinem Programm berücksichtigt. Aber Probleme gibt's, wenn man z.B. auf einer Solaris-Kiste verschlüsselt und auf einem ZOS-Hobel mit EBCDIC-Zeichensatz entschlüsseln möchte...

Ansonsten Danke für die Links, werde ich mir mal genauer ansehen. Vielleicht baue ich es auch noch mit ein (kann ja nix schaden...)

as3jg

@LordCyrix,

so, ich hab's mir angesehen und damit ein wenig rumgespielt. Dabei stellte ich fest, wenn ich für a, b, y, und p wirklich große Zahlen nehme, z.B. y=859 und p=811, laufen mir in C alle Zahlentypen (double oder long) über Gehe ich recht in der Annahme, daß man dafür sich eigene Rechenroutinen schreiben muß, die mit extrem großen Zahlen umgehen können? Oder habe ich nur was falsch verstanden?

Zum Anderen erhalte ich dann einen Schlüssel, eine relativ kleine Zahl, die sich bequem mit einer for(;;) Schleife durchtesten läßt. Was nützt mir die? Z.B. als Startwert einer random() Funktion, mit der ich verschlüsseln könnte, ist sie, wie gesagt, einfach mit einer for(;;) Schleife zu knacken.

Laß mich nicht dumm sterben ;-)

Nornagest

also prinzipiell möchte ich behaupten, dass deine Primzahlen dafür (afaik) VIEL zu klein sind (im Vergleich zu professionellen Lösungen)

Gulliver

was hier mit den Modulooperationen angesprochen wurde, ist Eulers Erbe.

und der algorithmus (Nornagest) ist letztendlich der RSA Algo.

@as3jg
das mit den Zahlen stimmt praktisch Sinn macht es, wenn Du zahlen nimmst die eine mindestlänge
von 200 Stellen haben, wobei hier gilt : je mehr desto sicherer.

und ja, du musst dir eigene Datentypen bauen, das Stichwort : Integerarithmetik

es gibt aber bereits einige gute kryptolibs, die auch modluooperationen auf grossen zahlen supporten.

mfg

silent

Hey eigentlich ist keine verschlüsselung sicher
zwar wird sie sicherer des to länger der schlüssel ist
aber im endefeckt kann man sie mit der häufigkeits analüse knacken!!!
ich will dazu jetzt aber kein breites szenario schreiben
aber von jedem script kiddie wird es nicht zu knacken sein
denn das prinzip der vignere-verschlüsslung fordert zeit um enmtschlüsselt zu werden

silent

as3jg

Moin,

schau dir mal meinen ersten Post an, mit den beiden Beispielen. Mit Häufigkeitsanalyse knackst du da gar nix. Oder, wenn doch, laß uns an deinem Wissen teilhaben.

Ferner gibt es sehr wohl unknackbare Verschlüsselungen, wie ich in den letzten Wochen herausfinden durfte. Nämlich Einweg-Schlüssel. Die sind nur knackbar, wenn a) der Schlüssel bescheuert ist, z.B. alles 0x00 oder b) jemand die Schlüssel physikalisch in seine Gewalt bringt, also klaut. Und mit dem Diffie-Hellman-Kistenmodell kombiniert, bekommt man sogar eine sichere Kommunikation hin.

Mein Progrämmchen unterstützt seit neuestem so etwas, für die letzte Version guckst du hier:
http://mitglied.lycos.de/JoergGrohne/mixit.html

silent

ich bleibe dabei im das grunde jede verschlüsselung,
zumindest theoretisch zu knacken dein prog ist abr trotzdem cool
was du meinst ist glaube ich ne art von modul-arithmetik
und ist ziemlich unmöglich zu knacken weil man eben
nur schwer erechenen kann:
z.B.:

>>>>>>>>>0>>>>>>>
>>>>6>>>>>>>>>1>>>
>>>>>>>>>>>>>>>>>
>>>>5>>>>>>>>>2>>>
>>>>>>>>>>>>>>>>>
>>>>>>>4>>>3>>>>>


4+4 nicht 8
sondern 4+4=1
und das ist in der tat schwer zu knacken mit zahlen wie

453^x (mod 21997)
sezten wir für x 5787 ein würden ein haufen rechner zusammen geschlossen
sehr lange dran arbeiten

um ne wirklich sichere verschlüsselung bietet allein der Quantencomputer


silent

as3jg

Moin,

leider muß ich dir widersprechen, es gibt EINE Verschlüsselung, die unknackbar ist. Nämlich die Einwegschlüssel.

Laß dir mal folgendes Beispiel auf der Zunge zergehen, einen kleinen Datenaustausch nach Diffie-Hellman:

A tauscht mit B geheime Nachrichten aus

Die Nachricht von A lautet 65.
Der geheime Schlüssel von A lautet 7
Der geheime Schlüssel von B lautet 2..
Also schickt A die Zahl 72 (65+7) an B.
Der kann damit nu garnichts anfangen und verschlüsselt mit seinem Schlüssel und schickt 74 (72+2) an A.
A entfernt seinen Schlüssel (74-7=67) und schickt 67 an B.
B entfernt seinen Schlüssel (67-2=65) und erhält 65 als geheime Nachricht.

Folgende Zahlen werden öffentlich (eMail, Briefpost, Telefon,...) übermittelt und können somit abgefangen werden:
72 und 74.

Ohne Kenntnis der beiden Schlüssel ist es unmöglich, die Botschaft (65) zu ermitteln.

Außer, du versuchst es mit roher Gewalt. Man ersetze also den Schlüssel mit jedem möglichen Wert, der geht von 0-255. Dann erhälst du als Ergebnis alle Zahlen von 0-255. Du kannst aber nicht beurteilen, welches die richtige Zahl ist.

Das heißt, du kannst nur raten und per Zufall die richtige Zahl erwischen.

Jetzt stelle dir mal vor, eine Telefonnummer wird ausgetauscht, die Schlüssel müssen natürlich genau so lang sein wie die Nachricht und sie müssen rein zufällig sein:

"004951127888921"
Schlüssel von A ist
"aREd82 4xxz7kr4"
Schlüssel von B ist
"XXXKd8ekjd78ei"

Und wieder kannst du nur raten und erhälst als Ergebnis ALLE möglichen und unmöglichen Telefonnumern in dieser Länge. Da ist es fast einfacher, sich alle Telefonbücher dieser Welt zu besorgen und von Hand durchzuprobieren.

Wie gesagt, wichtig dabei ist, die Schlüssel nur einmal zu verwenden. Sollte durch irgend einen dummen Zufall EIN Schlüssel geknackt werden, nützt das gar nichts, da bei der nächsten Verschlüsselung schon wieder ein neuer Schlüssel zum Einsatz kommt und das Spiel von vorne beginnt. Und die Schlüssel müssen zufällig sein, sie dürfen kein System aufweisen, dann ist es wirklich unknackbar.

Das Mischen von Daten benutze ich zur Zeit nur noch, um die Struktur der Daten zu zerstören, um eine Häufigkeitsanalyse ins Leere laufen zu lassen.

Ich glaube, die Kombination beider Methoden, Mischen und Einwegschlüssel, ist absolut sicher. Mir fällt jedenfalls nix ein, wie man so etwas knacken möchte.

Und durch die Art der Verschlüsselung, nämlich simples draufaddieren und dann Modulo 255, ist es auch eine Einwegfunktion