| Autor |
Beitrag |
Motzi
 
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Mo 07.07.03 16:08
Hallo allesamt!
Da immer wieder das Stichwort "XOR-Verschlüsselung" fällt und O'rallY mich gebeten hat ob ich nicht vielleicht meine zwei in diesem Thread beschriebenen Programme mit Source veröffentlichen kann (was ich innerhalb der nächsten Tage tun werde) dachte ich mir nur die Progs ohne kurze Erklärung bringen nicht viel, außerdem soll ein für alle mal unmissverständlich klargestellt werden, dass simple XOR-Verschlüsselungen (mit ein paar Ausnahmen) definitiv nicht sicher sind.
WICHTIG: dieses Tutorial soll nicht zu illegalen Handlungen auffordern! Es ist lediglich für Lern- bzw. Übungszwecke und als Beweis der Unsicherheit von simplen XOR-Verschlüsselungen gedacht!
Nachfolgender Text bezieht sich (der Einfachheit halber) speziell auf das knacken normaler deutscher Texte, man kann das Prinzip jedoch auch sehr leicht auf Texte umlegen die in andren Sprachen abgefasst wurden. Für andere Dateien als simple Texte muss man die Sache ein bisschen anders angehen, aber auf das werde ich hier nicht weiter eingehen...
Ich werde der Vollständigkeit halber zwar immer wieder ein paar kleine Codestücke einbauen, aber generell bezieht sich der Text eher auf die 2 Programme die ich in nächster Zeit noch veröffentlichen werde (Links folgen sobald die Progs veröffentlicht sind).
Eine simple XOR-Verschlüsselung:
Eine simple XOR-Verschlüsselung macht nichts anderes, als die Zeichen eines Passwortes den Zeichen der zu verschlüsselnden Daten (dem Klartext) per XOR zu vernknüpfen - daraus resultiert dann der sogenannte Chiffre-Text. Ein Beispiel für eine simple XOR-Verschlüsselung:
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
| procedure EncodeStream(aSource, aTarget: TStream; const sKey: String);
const
MAX_COUNT = 10240;
var
szBuffer: array [1..MAX_COUNT] of Byte; i: Integer;
iKeyPos: Integer; iReadCount: Integer; begin
aSource.Seek(0, soFromBeginning);
aTarget.Size := aSource.Size;
aTarget.Seek(0, soFromBeginning);
iKeyPos := 1;
while aSource.Position < aSource.Size do
begin
iReadCount := aSource.Read(szBuffer, MAX_COUNT);
for i := 1 to iReadCount do
begin
if iKeyPos > Length(sKey) then
iKeyPos := 1;
szBuffer[i] := szBuffer[i] xor Ord(sKey[iKeyPos]);
Inc(iKeyPos);
end;
aTarget.Write(szBuffer, iReadCount);
end;
end; |
Der Parameter aSource gibt einen Stream mit dem Klartext an, und aTarget stellt einen Stream dar, in dem die Prozedur den Chiffre-Text ablegt.
Wie kann man einen solchen Chiffre-Text nun knacken?
Die Koinzidenzerfassung
Die Koinzidenzerfassung basiert auf einem einfachen Prinzip - man "shiftet" (verschiebt) den Chiffre-Text um eine bestimmte Anzahl an Bytes und vergleicht dann den verschobenen Chiffre-Text mit dem original Chiffre-Text und zählt wieviele Bytes übereinstimmen. Wurde der Chiffre-Text um ein Vielfaches der Schlüssellänge verschoben, so liegt die Anzahl der übereinstimmenden Bytes bei etwas über 6%, andernfalls sind es weniger als 0.4%. Das lässt sich recht einfach erklären:
Da der Schlüssel i.A. kürzer ist als der Text (andernfalls würde es sich um ein OneTimePad handeln, welches unter bestimmten Vorraussetzungen 100% sicher ist, also nicht geknackt werden kann) wiederholt sich der Schlüssel periodisch. Beträgt die Verschiebung nun ein Vielfaches der Schlüssellänge, so sind die Bytes des verschobenen Chiffre-Textes und die Bytes des original Chiffre-Textes an denselben Stellen mit denselben Zeichen des Schlüssels XOR-verknüpft worden. Aufgrund der unterschiedlichen Auftrittswahrscheinlichkeit einzelner Zeichen in einem einfachen Text (zB. Leerzeichen oder das im Deutschen sehr häufig verwendete "e") besteht eine doch sehr hohe Chance, dass der verschobene Chiffre-Text und der original Chiffre-Text dasselbe Zeichen an derselben Stelle haben. Beträgt die Verschiebung nun ein Vielfaches der Schlüssellänge (sind also beide Zeichen mit demselben Schlüssel-Zeichen verschlüsselt worden), dann haben wir eine Übereinstimmung gefunden.
Die kleinste Verschiebung, die ein Vielfaches der Schlüssellänge ergibt, ist dann die gesuchte Länge des Schlüssels.
Wenn man nun die Schlüssellänge kennt verschiebt man den original Chiffre-Text um die Schlüssellänge und verknüpft den verschobenen Chiffre-Text mit dem original Chiffretext. Damit wird der Schlüssel entfernt und es verbleibt der Klartext XOR-verknüpft mit dem um die Schlüssellänge verschobenen Klartext. Da beim verschobenen Chiffre-Text und dem original Chiffre-Text ca. 6% der Bytes übereinstimmen hat man nach der XOR-Verknüpfung an diesen Stellen dann Zeichen mit dem HEX-Wert $00. Das bedeutet, dass an dieser Stelle mit großer Wahrscheinlichkeit ein Zeichen steht, dass in der jeweiligen Sprache sehr oft vorkommt. Und auf dieser Tatsache baut dann der nächste Schritt auf...
Die Kryptanalyse
Dieser Teil ist im Vergleich zur Koinzidenzerfassung verhältnismäßig einfach! Während die Koinzidenzerfassung aus einem gut durchdachten Algorithmus besteht, besteht die restliche Kryptanalyse eigentlich nur mehr aus gutem raten und ein bisschen logischer Kombination. Aus diesem Grund bezieht sich dieser Text auch hauptsächlich auf das Programm (welches leider noch nicht veröffentlich werden kann). Auch wenn dieser Teil eigentlich einfacher ist als die Koinzidenzerfassung, so ist das Programm dennoch ungleich komplexer, da ich viele kleine Hilfen und Unterstützungen eingebaut hab, die das analysieren des Textes wesentlich erleichtern.
Das Prinzip ist absolut simpel: man sucht im "dechiffrierten" Text (das Ergebnis der Koinzidenzerfassung - der Chiffre-Text der mit dem um x verschobenen Chiffre-Text XOR-vernküpft wurde) das erste Vorkommen des Zeichens mit dem HEX-Wert $00 (in meinem Programm werden diese Zeichen zum leichteren finden extra hervorgehoben). Nun ratet man einfach mal welches Zeichen das im Klartext sein könnte (meistens ist es ein sehr häufig auftretendes Zeichen) und berechnet dann aus dem geratenen Zeichen und dem Zeichen des original Chiffre-Textes das Zeichen des Schlüssels an jener Position. Somit kann man schonmal einen Teil des Textes entschlüsseln und ausgehend von diesen Teilen weitere Rückschlüsse ziehen. zB: auf ein Zeichen mit dem Wert $0D folgt meistens ein Zeichen mit dem Wert $0A (Zeilenumbruch), genauso wie normalerweise auf die Satzzeichen (.,;!?) meistens ein Leerzeichen folgt (mein Programm gibt extra Hinweise aus, sofern es solche häufig auftretenden Kombinationen findet, genauso wie es Warnungen ausgibt, wenn ein eigentlich entschlüsseltes Byte ein nicht darstellbares Zeichen ist). So kann man sich nun Stück für Stück Zeichen des Klartextes erarbeiten, daraus die Zeichen des Passwortes berechnen und damit wiederum den gesamten Text Stück für Stück entschlüsseln.
Ich werde das ganze später noch an einem Beispiel verdeutlichen.
Kurzer Hinweis: der gesamte Text inkl. Code wurde auf meinem Zivi-Arbeitsplatz aus dem Kopf geschrieben und kann daher momentan noch Fehler enthalten. Sobald ich zu Hause bin und mal Zeit hab werd ich das ganze nochmal überarbeiten und diesen Hinweis entfernen. _________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
Zuletzt bearbeitet von Motzi am Di 08.07.03 11:55, insgesamt 1-mal bearbeitet
|
|
Gast
Gast
Erhaltene Danke: 1
|
Verfasst: Mo 07.07.03 17:38
Frage ... IMHO hatte ich mal zu Pascalzeiten (Source deswegen abhanden gekommen) ein Prog geschrieben, welches die vorhergehenden Ergebnisse mit in die Verschluesselung einbezog. Wie saehe es mit dem knacken solcher Sachen aus?
Bsp: bla[i]:=bla[i-1] xor bla[i]
Weiss jetzt nicht, ob mein Bsp ueberhaupt liefe ... aber mal so prinzipiell.
Ich meine, da man sich den Algo per Disassembler holen kann, ist es sowieso keine Frage der Schluesselstaerke ... 
|
|
Motzi 
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Mo 07.07.03 19:09
Ich weiß zwar jetzt nicht genau wie/was du meinst aber ich denke schon, dass es auch relativ leicht geknackt werden kann (vielleicht mit ein bisschen mehr Aufwand). Man muss dazu sagen, dass XOR nicht generell unsicher ist.. XOR wird auch in den moderenen Algorithmen gerne eingesetzt, einfach weil es leicht umkehrbar ist, aber es geht speziell um die simple Verschlüsselung so wie oben gepostet. Viele Script-Kiddies oder Programmierer die sich einfach nicht mit der Materie auskennen versuchen dann oft die simple XOR Verschlüsselung mit irgendwelchen Tricks möglichst kompliziert zu gestalten, aber das endet meistens dennoch in einer Verschlüsselung die genauso linear abläuft wie die simple XOR-Verschlüsselung und daher auch genauso leicht zu knacken ist!
_________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
Motzi
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Di 08.07.03 12:26
Das OneTimePad - 100%ige Sicherheit (mit XOR)
Es ist unglaublich aber wahr, es gibt das perfekte Verschlüsselungskonzept, das 100%ige Sicherheit bietet! Es nennt sich One-Time-Pad (Einmalblock) und wurde im Jahr 1917 von Major Joseph Mauborgne und Gilbert Vernam von AT&T entwickelt.
Das Prinzip des OneTimePad (kurz OTP) ist ebenso einfach wie genial: der Schlüssel ist genauso lang wie der Klartext und ist zufällig(!!) erzeugt. Nun wird jedes Zeichen des Klartextes mit einem Zeichen des Schlüssels XOR-verknüpft.
Solange ein Schnüffler keinen Zugang auf das One-Time-Pad erlangt, das zur Verschlüsselung der Nachricht verwendet wurde, ist dieses Konzept absolut sicher.
Da der Schlüssel zufällig erzeugt wird ist jede Schlüsselsequenz gleich wahrscheinlich, womit ein völlig willkürlicher Chiffre-Text entsteht. Ein bestimmter Chiffretext kann mit derselben Wahrscheinlichkeit zu jedem der möglichen Klartexte gleicher Länge gehören und da jede Klartextnachricht gleich wahrscheinlich ist, gibt es für den Kryptanalytiker keine Möglichkeit zu ermitteln, welche davon die richtige ist. Eine zufällig gewählte Schlüsselsequenz, die zu einem nicht zufälligen Klartext addiert wird, erzeugt einen völlig willkürlichen Chiffretext. Keine noch so überragende Rechen- bzw. Verarbeitungsleistung kann daran irgend etwas ändern.
Die Vorbehalte gegen diese Methode, und diese sind nicht zu vernachlässigen, beziehen sich darauf, dass die Schlüsselsequenz zufällig generiert werden muss. Jeder Angriff gegen dieses Konzept wird sich auf das Verfahren konzentrieren, das zur Erzeugung der Schlüsselbuchstaben verwendet wird. Generatoren von Pseudozufallszahlen zählen hier nicht, da sie immer eine gewisse Regelmäßigkeit aufweisen. Nur wenn eine echte Zufallszahlenquelle benutzt wird ist die Sache sicher. Dies ist jedoch wesentlich schwieriger, als es auf den ersten Blick erscheinen mag.
Der andere entscheidende Punkt ist, dass man die Schlüsselsequenz unter keinen Umständen nochmal verwenden kann. Selbst wenn ein mehrere Gigabyte umfassender Block benutzt wird, kann ein Kryptanalytiker den Klartext rekonstruieren, sofern er über mehrere Chiffretexte verfügt, deren Schlüssel sich überschneiden. Dazu verschiebt er die Chiffretexte paarweise gegeneinander und zählt jeweils die Anzahl der Übereinstimmungen. Wenn sie richtig ausgerichtet sind, steigt der Prozentsatz der Übereinstimmungen sprunghaft an, wobei der genaue Wert von der Klartextsprache abhängt. Ab diesem Punkt ist die Kryptanalyse einfach.
Unsichere OneTimePads
Wie nun bereits mehrmals erwähnt wurde muss der Schlüssel des OTPs zufällig erzeugt werden und zwar mittels eines echten Zufalls! Echter Zufall basiert immer auf reellem Zufall, da die Realität viel zu komplex ist als dass sie einfach berechnet werden könnte. Pseudo-Zufalls-Generatoren wie das von Delphi bekannte Random/Randomize fällt nicht unter die Kategorie "echter Zufall" und kann mittels Brute-Force innerhalb kürzester Zeit geknackt werden (auf www.programmierer-board.de hab ich das schonmal gezeigt).
Wieso das so einfach geht:
Es gibt 2 Arten mit Random zu arbeiten - entweder man initialisiert die Ausgangswerte mit Randomize oder aber manuell über RandSeed. Aber egal mit welcher Methode man arbeitet, RandSeed kann höchstens 2^32 verschiedene Werte annehmen, und da Random auf RandSeed basiert kann Random höchstens 2^32 verschiedene Zufallsfolgen erzeugen - und 2^32 verschiedene Möglichkeiten sind schnell durchprobiert! Basiert der Algorithmus auf Randomize, so vereinfacht sich die Sache nochmal um ein vielfaches! Randomize initialisiert die Variable RandSeed mit der Anzahl der seit 00:00 vergangenen Millisekunden. Wenn man sich nun ausrechnet wieviele Millisekunden ein Tag hat, so stellt man fest, dass es bei Randomize nur 24*60*60*1000=86400000 (msec) verschiedene Möglichkeiten gibt, also rund 49 mal weniger als RandSeed aufnehmen könnte. Ein Brute-Force Angriff auf ein derartiges System dauert also höchstens ein paar Minuten. Aufgrund des erwähnten Threads auf www.programmierer-board.de hab ich auch ein Programm für eine derartige Brute-Force Attacke geschrieben, welches ich hier später auch noch veröffentlichen werde.
_________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
hitstec
Beiträge: 295
|
Verfasst: Do 10.07.03 03:09
Sehr interessant!
Ein paar Fragen zu Random hätte ich da noch.
Nehmen wir an der Schlüssel besitzt die Länge 255. Um das erste Zeichen per Zufall zu ermitteln, hat man 2^32 Möglichkeiten zur Auswahl. Da aber der Schlüssel nicht nur aus einem Zeichen, sondern aus 255 besteht, sind die Möglichkeiten des Schlüssels doch eigentlich um ein vielfaches höher.
Oder, habe ich einen falschen Ansatz?
Ein Brute-Force Angriff hätte dadurch eine um ein vielfaches höhere Laufzeit, soweit ich weiß steigt die Anzahl der Möglichkeitn exponentiell.
Dann wollte ich mit dem Vorurteil einer 100%igen Sicherheit aufräumen. Denn wie perfekt die Verschlüsselung auch sein kann, es gibt immer mind. eine Möglichkeit, wie man die Verschlüsselung knackt - und zwar mit dem eigentlichen Passwort.
Weiterhin hätte ich eine Idee. Da ich selbst eine Kennwortverwaltung geschrieben habe - schon eine Ewigkeit her - habe ich mich insbesondere mit dem Maskieren von Zeichenketten befasst.
Nun, was wäre wenn man zur Verschlüsselungszeit ein OneTimePad generiert (von mir aus erstmal mit Random) und diesen dann mit einer starken Verschlüsselung abhängig vom Benutzerkennwort verschlüsselt ablegt? Die Verschlüsselten Daten trennt man darauf von den verschlüsselten OneTimePads, die seperat aufbewahrt werden.
|
|
Motzi
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Mo 14.07.03 12:35
| hitstec hat folgendes geschrieben: | Sehr interessant!
Ein paar Fragen zu Random hätte ich da noch.
Nehmen wir an der Schlüssel besitzt die Länge 255. Um das erste Zeichen per Zufall zu ermitteln, hat man 2^32 Möglichkeiten zur Auswahl. Da aber der Schlüssel nicht nur aus einem Zeichen, sondern aus 255 besteht, sind die Möglichkeiten des Schlüssels doch eigentlich um ein vielfaches höher.
Oder, habe ich einen falschen Ansatz?
Ein Brute-Force Angriff hätte dadurch eine um ein vielfaches höhere Laufzeit, soweit ich weiß steigt die Anzahl der Möglichkeitn exponentiell. |
Nein... die gesamte Reihe der Zufallszahlen basiert auf einer einzigen 32bit Variable (-> RandSeed). Anhand dieser Variable wird die erste Zufallszahl berechnet und dann die Variable RandSeed neu berechnet. Die nächste Zufallszahl basiert dann wieder auf dem neuen Wert von RandSeed. D.h. es gibt nur 2^32 verschiedene Zufallls-FOLGEN! Nicht umsonst darf man Randomize nur einmal aufrufen. Würde man Randomize in einer Schleife immer wieder aufrufen und sich die erste Zufallszahl ausgeben lassen, so wäre es immer dieselbe (sofern die Laufzeit der Schleife weniger als 1ms beträgt)! Der Grund liegt einfach darin, dass RandSeed in der Schleife immer wieder mit derselben Anzahl an ms initialisiert wird weshalb die Berechnung der ersten Zufallszahl immer gleich ausfällt. D.h. hat man einmal den richtigen Wert für RandSeed kann der Schlüssel noch so lang sein - er kann komplett rekonstruiert werden!!
| Zitat: | Dann wollte ich mit dem Vorurteil einer 100%igen Sicherheit aufräumen. Denn wie perfekt die Verschlüsselung auch sein kann, es gibt immer mind. eine Möglichkeit, wie man die Verschlüsselung knackt - und zwar mit dem eigentlichen Passwort.
|
Wie darf ich das verstehen? Eine Verschlüsselung soll ja wieder umkehrbar sein, es muss also eine Möglichkeit geben aus dem Chiffre-Text wieder den Klartext zu bekommen! 100%ig sicher ist das ganze dann, wenn dies nur mit Kenntniss des Schlüssels (und des benutzten Algorithmus) funktioniert - und genau diese Sicherheit bietet das OTP! Eine nicht reversible "Verschlüsselung" stellt hingegen eine OneWay-Hash-Funktion dar...
| Zitat: | Weiterhin hätte ich eine Idee. Da ich selbst eine Kennwortverwaltung geschrieben habe - schon eine Ewigkeit her - habe ich mich insbesondere mit dem Maskieren von Zeichenketten befasst.
Nun, was wäre wenn man zur Verschlüsselungszeit ein OneTimePad generiert (von mir aus erstmal mit Random) und diesen dann mit einer starken Verschlüsselung abhängig vom Benutzerkennwort verschlüsselt ablegt? Die Verschlüsselten Daten trennt man darauf von den verschlüsselten OneTimePads, die seperat aufbewahrt werden. |
Hm.. ehrlich gesagt versteh ich nicht ganz was du meinst...  aber soweit ich das seh ist das auch nicht sicherer, da das ganze im Endeffekt wieder nur auf dem Passwort des Benutzers und deiner verwendeten "starken" Chiffrierung. _________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
hitstec
Beiträge: 295
|
Verfasst: Mo 14.07.03 13:43
| Zitat: | | Wie darf ich das verstehen? |
Ganz einfach. Es gibt keine 100%ige Sicherheit! Wenn du natürlich die Definition dessen umschreibst und es so hinstellst, wie du es beschrieben hast, dann schon.
100%ige Sicherheit bedeutet, dass niemand außer dir selbst Zugang auf deine verschlüsselten Daten erlangen kann. Da das weder theoretisch noch praktisch nichg möglich ist, existiert auch die 100%ige Sicherheit nicht. Jede verschlüsselte Information lässt sich unter bestimmten Bedingungen mithilfe von Brute Force dechiffrieren. Und dann haben wir ja noch den Zufall. Es ist immerhin möglich, wenn auch unwahrscheinlich, dass jemand zufällig das richtige Kennwort eingibt.
Und das mit Randseed leuchtet mir irgendwie nicht ein. Willst du damit auf die Reproduzierbarkeit der Pseudozufallszahlen hinaus?
|
|
Motzi
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Mo 14.07.03 14:13
| hitstec hat folgendes geschrieben: | | Jede verschlüsselte Information lässt sich unter bestimmten Bedingungen mithilfe von Brute Force dechiffrieren. Und dann haben wir ja noch den Zufall. Es ist immerhin möglich, wenn auch unwahrscheinlich, dass jemand zufällig das richtige Kennwort eingibt. |
Nein, eben nicht!  Das OneTimePad wird zufällig erzeugt, das Ergebnis ist also ein völlig willkürlicher Chiffre-Text! Es gibt also unendlich viele Klartexte, die mit dem entsprechenden Schlüssel ein und denselben Chiffre-Text ergeben. Und genau das ist der Punkt - ohne Kenntniss des verwendeten Schlüssel ist es unmöglich den Klartext zu rekonstruieren! Einzig und allein aufgrund der Tatsache, dass der Angreifer keine Möglichkeit hat festzustellen welcher der unendlich vielen möglichen Klartexte der richtige ist! In meiner Fachbereichsarbeit ist im Anhang auch noch eine Beschreibung des OTP, falls du Lust hast kannst du dir das auch noch anschaun - www.x-spy.net/personal
| Zitat: | | Und das mit Randseed leuchtet mir irgendwie nicht ein. Willst du damit auf die Reproduzierbarkeit der Pseudozufallszahlen hinaus? |
Ganz genau - es gibt nur 2^32 mögliche Zahlenfolgen die durch Random erstellt werden können. Um einen altbekannten Spruch zu missbrauchen - "Ein System ist immer nur so stark wie der schwächste verwendete Algorithmus!" Das System kann also noch so gut und komplex sein, wenn es auf einem Pseudo-Zufallsgenerator wie Random basiert, dann sinkt der Aufwand der für das knacken benötigt wird dennoch nur auf 2^32 Möglichkeiten! _________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
mirage228
Beiträge: 338
Win 7 Prof.
Delphi 2005 Prof., Delphi 2010 Prof.
|
Verfasst: Mo 14.07.03 14:19
sagen wir mal, ich weiss dass du einen deutschen Text mit OTP verschlüsselt hast. Dann könnte ich doch per Bruteforce alle Schlüsselkombos durchgehen (ja, ich weiss, dass das verdammt lange dauert...) und dann den text "entschlüsseln" und den chiffre-text durch ein analyse-programm jagen, der guckt, wieviele deutsche worte im text vorkommen. der text mit den meisten deutschen ausdrücken müsste dann doch der Originaltext sein oder????
_________________ May the source be with you, stranger.
|
|
Motzi
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Mo 14.07.03 14:37
| mirage228 hat folgendes geschrieben: | | sagen wir mal, ich weiss dass du einen deutschen Text mit OTP verschlüsselt hast. Dann könnte ich doch per Bruteforce alle Schlüsselkombos durchgehen (ja, ich weiss, dass das verdammt lange dauert...) und dann den text "entschlüsseln" und den chiffre-text durch ein analyse-programm jagen, der guckt, wieviele deutsche worte im text vorkommen. der text mit den meisten deutschen ausdrücken müsste dann doch der Originaltext sein oder???? |
Nein, eben nicht!! Der "Schmäh" bei dem OneTimePad ist ja, dass der Chiffre-Text entschlüsselt JEDEN möglichen Klartext ergeben kann. Zur Verdeutlichung hier die Beispiele aus meiner Fachbereichsarbeit (diese Beispiele basieren auf der klassischen Verschlüsselung per OTP - man nehme die Positionen der Buchstaben im Alphabet, addiere diese und rechne das Ergebnis modulo 26).
Der Klartext lautet: ONETIMEPAD
und der Schlüssel ist: TBFRGFARFM
dann ergibt der Chiffre-Text: IPKLPSFHGQ
Der Angreifer hat nun keine Möglichkeit festzustellen, welcher Schlüssel bzw welcher Klartext der richtige ist. Denn da der Schlüssel zufällig erzeugt wird sind die Schlüssel EAUVKGDCMW oder UUGGDZEVFW genauso wahrscheinlich wie der richtige Schlüssel! Nur, dass der entschlüsselte Text dann DOPPELBETT oder NUDELSALAT lautet...
Auch für dich nochmal der Hinweis auf meine Fachbereichsarbeit, vielleicht ist die Beschreibung dort besser/verständlicher - www.x-spy.net/personal_________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
mirage228
Beiträge: 338
Win 7 Prof.
Delphi 2005 Prof., Delphi 2010 Prof.
|
Verfasst: Mo 14.07.03 17:31
Ach, so ist das
Ich hätte den Teil mit dem OTP in deiner Facharbeit (übrigens super gelungen ) doch besser lesen sollen...
Dann ist das ja wirklich super sicher 
Ich glaube XOR-OTP kommt jetzt auch in die nächste Version meines Verschlüsselungsprogrammes
mfG
mirage228 _________________ May the source be with you, stranger.
|
|
Motzi
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Mo 14.07.03 17:37
_________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
mirage228
Beiträge: 338
Win 7 Prof.
Delphi 2005 Prof., Delphi 2010 Prof.
|
Verfasst: Mo 14.07.03 19:04
| Motzi hat folgendes geschrieben: | | Dann aber bitte nur mit echtem(!!) Zufall!! |
Japp, bin auch schon auf der Suche nach Algorythmen bzw. Komponenten dafür... aber bisher nix gefunden...
mfG
mirage228
P.S.: In den Readmes meiner Verschlüsselungskompos steht was von "High Quality RNG"... was muss ich mir drunter vorstellen? _________________ May the source be with you, stranger.
|
|
Motzi
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Di 15.07.03 10:52
| mirage228 hat folgendes geschrieben: | | Japp, bin auch schon auf der Suche nach Algorythmen bzw. Komponenten dafür... aber bisher nix gefunden... |
Es gibt verschieden Möglichkeiten.. such mal ein bisschen im Internet (aber nicht nach Komponenten, das schaffst du auch selber..)! Der Typ aus dem programmierer-board dessen Randomize-OTP ich per Brute-Force geknackt hab hat dann eine neue Version rausgebracht, die auf der Zufälligkeit von Mausbewegungen basiert...
| Zitat: | | P.S.: In den Readmes meiner Verschlüsselungskompos steht was von "High Quality RNG"... was muss ich mir drunter vorstellen? |
RNG = Random Number Generation (falls dus noch nicht gewusst hast ) Um welche Kompo handelt es sich dabei? _________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
hitstec
Beiträge: 295
|
Verfasst: Di 15.07.03 11:23
Doch, deine Facharbeit finde ich nicht schlecht. Sehr einfach zu verstehen.
| Zitat: | | Nein, eben nicht! Das OneTimePad wird zufällig erzeugt, das Ergebnis ist also ein völlig willkürlicher Chiffre-Text! |
Achso, klar. Ungefähr so arbeitet meine Kennwortverwaltung. Sie generiert aus Textinformation eine Art Hash-String, das als Kennwort benutzt wird. Im Gegensatz zum OneTimePad ist dieser natürlich nicht umkehrbar. Der Vorteil dieser Kennwortverwaltung ist, das keinerlei Informationen gespeichert werden müssen, sodass Kryptoanalytiker so gut wie keinen Ansatz hätten, um solche Kennwörter zu rekonstruieren.
Allerdings ist der Algo zum generieren des Hashs ziemlich schwach und besitzt bestimmt einige Einschränkungen. Vielleicht schaust du dir das Tool kurz an und sagst mir, was du davon hälst.
PS:
| Zitat: | | Randomize-OTP ich per Brute-Force geknackt hab |
Wie kann man das verstehen? Hast du die Reproduzierbarkeit des Algos herausgefunden oder wie?
|
|
Motzi
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Di 15.07.03 11:49
| hitstec hat folgendes geschrieben: | | Vielleicht schaust du dir das Tool kurz an und sagst mir, was du davon hälst. |
Klar, kann ich machen...!
| Zitat: | PS:
| Zitat: | | Randomize-OTP ich per Brute-Force geknackt hab |
Wie kann man das verstehen? Hast du die Reproduzierbarkeit des Algos herausgefunden oder wie? |
Schau dir am besten den entsprechenden Thread an, dort hab ichs auch erklärt: www.programmierer-bo...der=asc&start=15_________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
hitstec
Beiträge: 295
|
Verfasst: Di 15.07.03 12:08
Habe es mir gerade angeschaut: interessante Idee, so wie er das mit der Mausbewegung gemacht hat.
Also er benutzt zwar Randomize, aber er initialisiert vor dem tatsächlichen Random ein paar Randomwerte unter Verwendung der Mausbewegungen.
Allerdings sind diese Randomwerte von den Mausbewegungen selbst eigentlich nicht abhängig. Warum soll dann seine Methode sicher sein?
Wäre es nicht sicherer, wenn man möglichst viele Faktoren bei der Generierung eines möglichst echten Zufalls berücksichtigt?
PS: Meine Kennwortverwaltung findest du hier: www.kenngen.de.
|
|
Motzi
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Di 15.07.03 13:00
| hitstec hat folgendes geschrieben: | Habe es mir gerade angeschaut: interessante Idee, so wie er das mit der Mausbewegung gemacht hat.
Also er benutzt zwar Randomize, aber er initialisiert vor dem tatsächlichen Random ein paar Randomwerte unter Verwendung der Mausbewegungen.
Allerdings sind diese Randomwerte von den Mausbewegungen selbst eigentlich nicht abhängig. Warum soll dann seine Methode sicher sein? |
Nein, er berechnet aufgrund der Mausbewegungen echte Zufallszahlen - ohne Random!
| Zitat: | | Wäre es nicht sicherer, wenn man möglichst viele Faktoren bei der Generierung eines möglichst echten Zufalls berücksichtigt? |
Wenn der Zufall auf Realität basiert, dann hast du genug Faktoren drinnen (eben alle Faktoren der Realität)! Mehr brauchst du nicht..
Thx, werds mir wenn ich zu Hause bin mal anschaun... _________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
mirage228
Beiträge: 338
Win 7 Prof.
Delphi 2005 Prof., Delphi 2010 Prof.
|
Verfasst: Di 15.07.03 14:00
| Motzi hat folgendes geschrieben: | | mirage228 hat folgendes geschrieben: | | P.S.: In den Readmes meiner Verschlüsselungskompos steht was von "High Quality RNG"... was muss ich mir drunter vorstellen? |
RNG = Random Number Generation (falls dus noch nicht gewusst hast ) Um welche Kompo handelt es sich dabei? |
In dem Quelltext für die Keygeneration der RSA-Komponente steht:
{** get a random seed for the search - your routine
should use a high quality RNG to fill this seed **}
Die Komponenten für die Verschlüsselung habe ich von TSM Inc. _________________ May the source be with you, stranger.
|
|
Motzi
Beiträge: 2931
XP Prof, Vista Business
D6, D2k5-D2k7 je Prof
|
Verfasst: Fr 25.07.03 16:47
Wie versprochen hab jetzt (ein bisschen verspätet) die beiden Progs hier veröffentlicht: www.delphi-forum.de/viewtopic.php?t=14337_________________ gringo pussy cats - eef i see you i will pull your tail out by eets roots!
|
|
|
