OTP-Gen (One Time Pad Key Generator)

[sakura]

Hi DPler,

da ich gerade ein paar Randomdaten benötigte, möchte ich Euch diese Kreation nicht vorenthalten :mrgreen:

Wers benötigt mag es nutzen, wer es nicht braucht möge schweigen ;)

Der Code ist weder schön noch auf Fehler (volle Festplatte) hin gesichert. Und die Nach- und Vorteile von OTP-Cipher wurden in der DP schon zu genüge diskutiert. Na ja, es ist alle Male besser als ein einfacher Random-Generator.

Das Proggie benötigt das "LMD Tray Icon" in der vorliegenden Version, aber das kann umgangen werden ;)

Die OTP Datei wird mit der aktuellen Zeit als Namen im Startverzeichnis hinterlegt.

...:cat:...

P.S.: Das Proggie nutzt die Mausbewegungen als Grundlage. Einfach laufen lassen und den Datenmüll sammeln ;)

[sakura]

Update

• korrigiert: manchmal verliert der Hook seine Bindung, Timer für Reset :mrgreen:
• korrigiert: mehrere Mausereignisse ohne wirtliche Mausbewegung werden ignoriert

...:cat:...

[d3g]

Bist du dir eigentlich sicher, dass Mausbewegungen für einen OTP-Schlüssel ausreichend sind? Ich kenn mich mit der Materie jetzt nicht so sonderlich aus, aber sind Mausbewegungen nicht zu vorhersehbar, zumindest Stellenweise, sodass man zumindest Teile der verschlüsselten Nachricht entschlüsseln kann? Ich würde einfach weißes Rauschen vom Radio über die Soundkarte aufnehmen, das ist doch sicher zufälliger und bringt mehr Daten in kürzerer Zeit.

[sakura]

Wirklich ausreichend wohl nicht, aber besser als jeder Pseudo-Generator und für den Zweck, welchen ich brauche ausreichend. ;)

Wer will kann damit tun und lassen was er will.

...:cat:...

[d3g]

Zitat:

Zitat von sakura

Wirklich ausreichend wohl nicht, aber besser als jeder Pseudo-Generator und für den Zweck, welchen ich brauche ausreichend. ;)

OK. :mrgreen:

Zitat:

Zitat von sakura

Wer will kann damit tun und lassen was er will.

Naja, für ein Spionagetool könnte man den Source natürlich benutzen ;-) (bin ich froh, dass X11 ein Sicherungssystem gegen sowas hat...)

[toms]

Zitat:

korrigiert: manchmal verliert der Hook seine Bindung, Timer für Reset

Funktioniert immer noch nicht richtig. z.B wenn die Tastenkombinationen
Strg-Alt-Del oder Strg-Esc gedrueckt werden.
Lösung: WM_CANCELJOURNAL abfangen und dann Hook neu starten.

[GuenterS]

Zitat:

Zitat von d3g

Bist du dir eigentlich sicher, dass Mausbewegungen für einen OTP-Schlüssel ausreichend sind? Ich kenn mich mit der Materie jetzt nicht so sonderlich aus, aber sind Mausbewegungen nicht zu vorhersehbar, zumindest Stellenweise, sodass man zumindest Teile der verschlüsselten Nachricht entschlüsseln kann? Ich würde einfach weißes Rauschen vom Radio über die Soundkarte aufnehmen, das ist doch sicher zufälliger und bringt mehr Daten in kürzerer Zeit.

Naja sind nicht ganz vorhersehbar, wenn man sie zum Beispiel alle 1 oder 2 Sekunden abfragt und der User nicht ausgerechnet eine Gerade zieht *g*

Die Idee mit dem weißen Rauschen ist nicht schlecht, aber nicht jeder hat eine Radio Karte.

[sakura]

Zitat:

Zitat von GuenterS

Naja sind nicht ganz vorhersehbar, wenn man sie zum Beispiel alle 1 oder 2 Sekunden abfragt und der User nicht ausgerechnet eine Gerade zieht *g*

Einerseits dieses, andererseits speichere ich ja auch nicht die Koordinaten, das wäre wohl wirklich zu hirnlos, sondern den Wert aus

Delphi-Quellcode:

SpeicherByte := (MouseX + MouseY * BildschirmHoehe) mod 256;

Damit sollte das logische Nachverfolgen wirklich unmöglich sein - hoffe ich.

Gravierender Nachteil bleibt der Fakt, daß die Maus nur recht wenig bewegt wird und somit nur wenige Daten anfallen :wall:

...:cat:...

[GuenterS]

Naja dann forder den User doch auf mal die Maus kräftigst zu bewegen. Man könnte ja in den empfangen Daten prüfen in welchem Bereich sich die Maus bewegt hat und wenn dieser zu klein ist eine Warnung bzw. Fehlermeldung ausgeben.

[toms]

Zitat:

wenn dieser zu klein ist eine Warnung bzw. Fehlermeldung ausgeben.

oder einfach ignorieren.

[Ultimator]

Stimmt.

Es kommt vllt ein bisschen blöd, wenn plötzlich ein Programm zu einem sagt, man soll doch bitte die Maus in größeren Zügen bewegen. ;-)

[GuenterS]

Zitat:

Zitat von Ultimator

Stimmt.

Es kommt vllt ein bisschen blöd, wenn plötzlich ein Programm zu einem sagt, man soll doch bitte die Maus in größeren Zügen bewegen. ;-)

Naja wenn genau daraus die Zufallszahlen berechnet werden, ist das schon eine legitime Warnung an den Benutzer. Eventuell könnte man ja eine kleine Erklärung dazu abgeben um nicht in die Analen der sonderbarsten Fehlermeldungen einzugehen.

[Alexander]

Man kann auch für zu kleine Mausbewegungen einfach mit einem Faktor mutliplizieren o.ä.

[sakura]

Auch zu kleine Mausbewegungen sind i.A. kein Problem, da immer noch ein Produkt aus mehreren Faktoren gebildet wird.

Das Programm, wie es hier ist wird auch nicht weiter entwickelt, also lohnt sich die Diskussion eh nicht, es dient lediglich als Denkanstoß.

...:cat:...

[shmia]

Zitat:

Zitat von sakura

Gravierender Nachteil bleibt der Fakt, daß die Maus nur recht wenig bewegt wird und somit nur wenige Daten anfallen :wall:

Man könnte die Daten mit den untersten 8 Bits des CPU Taktzyklenzählers anreichern.
Dies funktioniert allerdings nur beim Pentium Prozessor.

Delphi-Quellcode:

{**************************************************************************
 * NAME:    GetCPUTick
 * DESC:
 * Processors Intel Pentium have a powerful command RDTSC.
 * This is an extraction from Intel documentation on this command:
 * "Loads the current value of the processor's time-stamp counter into the
 * EDX:EAX registers.
 * The time-stamp counter is contained in a 64-bit MSR.
 * The high-order 32 bits of the MSR are loaded into the EDX register,
 * and the low-order 32 bits are loaded into the EAX register.
 * The processor increments the time-stamp counter MSR every clock cycle and
 * resets it to 0 whenever the processor is reset."
 * Note that RDTSC command returns the values in Int64 format used in Delphi.
 *************************************************************************}
function GetCPUTick: Int64;
asm
   DB $0F,$31 // this is RDTSC command. 
              // it is not supported by the Delphi inline assembler
end;

[sakura]

@Shmia: Einen Vorteil kann ich daraus nicht erkennen :?

Aber Deine Funktion liefert Delphi/Windows bereits ohne den Assemblerteil: QueryPerformanceCounter

Vergleiche mal die Werte, Du wirst sehen, daß die immer sehr ähnlich sind - halt nur ein paar CPU-Ticks auseinander :zwinker:

...:cat:...

[shmia]

Zitat:

Zitat von sakura

@Shmia: Einen Vorteil kann ich daraus nicht erkennen :?

Die doppelte Datenmenge kann produziert werden:

Delphi-Quellcode:

var
   B : Word;
....
   // Mauskoodinaten & Zeitanteil zusammenfügen
   B := ((Value and 256) shl 8) or (GetCPUTicks and 256);  // oder QueryPerformanceCounter
   OutFile.Write(B, SizeOf(B));

[d3g]

Zitat:

Zitat von GuenterS

Die Idee mit dem weißen Rauschen ist nicht schlecht, aber nicht jeder hat eine Radio Karte.

Die ist auch nciht unbedingt nötig. Zwei Kupferdrähte, zwei 3,5mm-Klinken, ein Lötgerät, ein Radio mit Kopfhörer- oder Line-Ausgang und eine billige Soundkarte tun's auch. Die ersteren drei Punkte sind auch durch einen Besuch im Elektronikladen deiner Wahl austauschbar.

Zitat:

Zitat von sakura

Einerseits dieses, andererseits speichere ich ja auch nicht die Koordinaten, das wäre wohl wirklich zu hirnlos, sondern den Wert aus

Delphi-Quellcode:

SpeicherByte := (MouseX + MouseY * BildschirmHoehe) mod 256;

Damit sollte das logische Nachverfolgen wirklich unmöglich sein - hoffe ich.

Wenn der Angreifer die Bildschirmhöhe errät/ausprobiert, ändert das nichts. Die Problemgröße wird um einen konstanten Faktor erhöht, die Problemkomplexität aber gar nicht.

[MisterNiceGuy]

Boah keinen Plan worum es hier geht! Kann mich mal jemand aufklären was das Programm macht?!

THX :)

[d3g]

Zufallszahlen erzeugen. Und zwar möglichst wirklich zufällige und nicht vorhersehbare (wie z.B. aus einem Pseudozufallszahlgenerator wie Random()).

[sakura]

Zitat:

Zitat von d3g

Wenn der Angreifer die Bildschirmhöhe errät/ausprobiert, ändert das nichts. Die Problemgröße wird um einen konstanten Faktor erhöht, die Problemkomplexität aber gar nicht.

Ich glaube schon, da auch die Höhe zu wissen Dir absolut keinen Ansatz gibt, ausser der Nutzer bewegt seine Muas immer so langsam, das immer nur zusammenhängende Pixel abgetastet werden. Selbst wenn Du das versuchst, wirst Du kaum eine Chance haben. Persönlich glaube ich, daß die Daten weiterhin random bleiben.

...:cat:...

[alcaeus]

Ihr könnt ja folgendes machen:
100 mal 100 Zufallszahlen von 1 bis 100 generieren, und zwar einmal mit Random(), und einmal mit Sakuras Programm. Anschließend vergleicht ihr für jeden Block von 100 Zahlen den Mittelwert, Median, Varianz, etc. Wenn nun bei den Blöcken sehr häufig gleiche Varianz und Mittelwert bzw. Median rauskommen, dann ist es wahrscheinlich ein Pseudozufallsgenerator. Ich wünsche viel Spaß noch mit Statistik ;) :mrgreen:

Greetz
alcaeus

[d3g]

Zitat:

Zitat von alcaeus

Wenn nun bei den Blöcken sehr häufig gleiche Varianz und Mittelwert bzw. Median rauskommen, dann ist es wahrscheinlich ein Pseudozufallsgenerator.

Naja, ein guter Pseudozufallsgenerator zeichnet sich dadurch aus, dass er statistisch gesehen eine zufällige Verteilung der Zahlen erzeugt. Und 10000 Zahlen dürften nicht reichen, um eine Periode in der generierten Reihe feststellen zu können.

Zitat:

Zitat von sakura

Ich glaube schon, da auch die Höhe zu wissen Dir absolut keinen Ansatz gibt, ausser der Nutzer bewegt seine Muas immer so langsam, das immer nur zusammenhängende Pixel abgetastet werden. Selbst wenn Du das versuchst, wirst Du kaum eine Chance haben.

Ich vielleicht nicht, aber $INTELLIGENCE sehr wohl. Wenn zusammenhängende Pixel in den Schlüssel miteingehen, dann kann die Nachricht stellenweise ohne Probleme entschlüsselt werden.

[sakura]

Zitat:

Zitat von d3g

Ich vielleicht nicht, aber $INTELLIGENCE sehr wohl. Wenn zusammenhängende Pixel in den Schlüssel miteingehen, dann kann die Nachricht stellenweise ohne Probleme entschlüsselt werden.

Dann müssten es durchaus mehrere zusammenhängende (möglichst auf einer Geraden) Pixel sein. Aber hier ist ja auch nur der Ansatz präsentiert :zwinker:

...:cat:...

[d3g]

Zitat:

Zitat von sakura

Dann müssten es durchaus mehrere zusammenhängende (möglichst auf einer Geraden) Pixel sein.

So zusammenhängend müssen sie gar nicht sein, solange ungefähr auf einer Geraden. Mit genügend Rechenkraft ist alles machbar, da von einer bestimmten Mausposition aus recht zuverlässig Wahrscheinlichkeiten für die nächste Mausposition berechnet (bzw. beobachtet) werden können sollten. Wie auch immer, besser als Pseudozufallszahlen ist es allemal.

Zitat:

Zitat von sakura

Aber hier ist ja auch nur der Ansatz präsentiert :zwinker:

OK :mrgreen: