Hallo Hagen,


ich wollte auf Anregung in diesem Beitrag
Passwörter generieren.


http://www.delphi-praxis.de/topic747...e2c2145dd9c618

markieren

Code:

function Passwort: String
var
  Buffer: array[0..1023] of Byte;
begin
  CaptureInput(Buffer);
  Result := THash_MD5.CalcBuffer(Buffer, SizeOf(Buffer), fmtMIME64);
end;

Leider ist in Deinen DEC Sourcen nicht ein einziges mal der Begriff CaptureInput vorhanden.
Was macht diese Funktion ?
Ist das einfach eine Zufallsbefüllung des Buffers ?

bei THash_MD5.calcbuffer gibts noch einen Paramenter vom Typ TProtection.
kann der auf nil gesetzt werden ?


vielen Dank !

Gruß stoxx

CaptureInput() ist eine virtuelle Umschreibung für eine von dir zu programmierende Funktion die Input durch einen Menschen getätig capture'd also erfasst

Diese Funktion haste selber zu schreiben und ist garnicht so einfach wie man denkt. Das schwierigste Problem ist es dabei die Entropie = Verteilung der benutzten Daten zu berücksichtigen. Als Beispiel: die Aufgabe des Users ist es ein Lied in das Mikrophone zu pfeifen. Diesen Soundstream zeichnest du auf. Aber du darfst nun NICHT alle Bits eines Samples benutzten umd denn Human-Zufalls-Faktor zu extrahieren. Ein solches WAV besteht zB. aus 2x 16Bit Samples, eines pro Soundkanal bei Stereo. Von jedem dieser 2 16Bit Zahlen pro Sample darfst du NUR das unterste oder eventuell die zwei unteresten Bits extrahieren. Diese beiden Bits liegen im Wave, betrachtet als Soundkurve, um den "Nullpunkt" herum. Sie stellen also Rauschen dar das aber durch das Singen durch den Menschen eben unvorhersagbar und nicht reproduzierbar moduliert wurde, es ist aber eben Rauschen.

Nun, jetzt extrhierst du dies Daten aus dem Wave und diese landen im obigen Buffer[], der Hash darüber ist der Output des YARROW RNG.

Im Falle eines PCs sollte man den User wahllos auf dem Keyboard rumhacken lassen. Die untersten 1-2 Bits jedes ASCII Zeichens landen im Buffer, komprimiert. Angenommen 1 Bit pro ASCII Zeichen, somit ergeben 8 ASCII zeichen 1 Byte im Buffer. Oder du nimmst die Bewegungen der Maus. Auch hier werden nur die 1-2 Bits der X,Y Koordinate benutzt, oder eben die Parität der Koordinaten.

Ich hatte mal einen Code der über Mouse/Keyboard Hooks permanent im Hintergrund solche daten sammelte. ZUsätzlich wurde in der Registry ein 1024 Bytes großer Zufallsbuffer gespeichert. Beim Start der Anwendung werden die Hooks installiert, der interne Buffer mit dem in der Registry gespeicherten geladen, und dann jede Mousebewegung oder Tastendrücke in den Buffer per XOR eingearbeitet. Bei der Erzeugung eines Zufallswertes aus diesem Buffer wird nun dieser Buffer + einem Zähler (Counter) gehasht. Der Hash ist der Rückgabewert des Zufallsgenerators. Innerhalb der RNG Funktion wird natürlich der Counter jedesmal erhöht.

Param TProtection sollte nil sein.

Im Pseudocode sähe es so aus:

zusammenfalten · markieren

Delphi-Quellcode:

unit RNG;

interface

implementation

var
  Buffer: packed record
            Pos: Integer;
            Count: Integer;
            Data: array[0..1023] of Byte;
          end;

function MyMouseHook():
begin
  Buffer.Data[Buffer.Pos] := Buffer.Data[Buffer.Pos] shl (MousePos.X and 1) xor (MousePos.Y and 1);
  Buffer.Pos := (Buffer.Pos +1) mod 1024;
  Result := CallNextHookEx(...);
end;

fucntion MyKeyboardHook();
begin
  Buffer.Data[Buffer.Pos] := Buffer.Data[Buffer.Pos] shl (Key and 1) xor GetCurrentTick;
  Buffer.Pos := (Buffer.Pos +1) mod 1024;
end;

function PRNG: Integer;
type
  PDigest = ^TDigest;
  TDigest = array[0..3] of Cardinal; // = 16 Bytes für MD5 Digest

var
  Digest: PDigest;
begin
  Inc(Buffer.Count);
  with THash_MD5.Create do
  try
    Init;
    Calc(Buffer, SizeOf(Buffer));
    Done;
// errechne Result
    Digest := DigestKey;
    Result := Digest[0] xor Digest[1] xor Digest[2] xor Digest[3];
  finally
    Free;
  end;
end;

initialization
  Buffer.Pos := 0;
  Buffer.Count := 0;
  LoadBufferFromRegistry(Buffer.Data);

  SetWindowsHookEx(WH_MOUSE, MyMouseHook, ..);
  SetWidnowsHookEx(..., MyKeyboardHook, ...);
finalization
  UnhookWindowsHook(..., ....);

  SaveBufferToRegistry(Buffer.Data);
end.

Gruß Hagen

Hallo Hagen !

okay ! .. Danke, jetzt versteh ich das Problem erst

Aber mal noch eine ganz einfache Frage, (mich bitte nicht köpfen)

Wenn also der Buffer ein nicht reproduzierbaren Dateninput sein soll. Also zum Beispiel eine Mausbewegung.
Was spricht dagegen, die Mausbewegungen, bzw das Rauschen der Mausbewegung (1-2 Bits der Mauskoordinaten)
gleich als Passwort zu nehmen, und diese Bits herzunehmen, und damit ASCCI Zeichen für das Passwort zu generieren ?

Wozu braucht man dann noch MD5 Verschlüsselungen ?

Ein Passwort ist ja duzu da, um sicherzustellen, dass nur berechtiuge Benutzer die Daten einsehen können. Wenn du jetzt ein zufälliges generierst...denk mal weiter.

Zitat:

Wozu braucht man dann noch MD5 Verschlüsselungen ?

Eigentlich braucht man sie tatsächlich nicht da sich durch die Hash-Funktion NICHTS an der Qualität der "Unvorhersagbarkeit" und "Unreproduzierbarkeit" der "Zufalls"-Daten ändert.
ABER! es ist ein Unterschied ob man diese Eigenschaften "beweisen" oder nur als "logisch" annehmen kann. Die Hash Funktion ist eine klar mathematisch beweisbare Einweg Funktion. Somit wird durch die obige Hash-Funktion folgende logische Annahme ganz klar auch bewiesen:
1.) der Input kann nur vom gleichen Menschen mit exakt gleichen Umweltbedinungen reproduziert werden, so wie ein Fingerabdruck der bei gleicher Temaratur mit gleicher Seife gewaschen wurde.
2.) der durch die Hash Funktion erzeugte Output kann mit exakt berechnenbarem Aufwand zurück in seine möglichen Inputs berechnet werden. D.h. die Sicherheitsschranken der Einwegfunktion sind bekannt und ermöglichen es exakt die Aussage zu treffen das es mit heutiger Technik und Wissenstands mindestens 4 Milliarden Jahre dauert um die Hashfunktion umzukehren. Da die Hashfunktion auch eine "Kompressionsfunktion" ist, nützt selbst dieses nichts. Denn aus einem 1024 Bytes Buffer erzeugen wir einen 16 Bytes Hashdigest. Dieser Hashdigest ist mit einer Wahrscheinlichkeit von 1 zu 2^128 eindeutig zum 8192 Bit Input. Dennoch MUSS es 2^(8192 -128) verschiedene Buffer geben die den gleichen 128 Bit Digest erzeugen !! D.h. selbst wenn man 2^8192 verschiedene Buffer durchprobiert so findet man 2^(8192 - 128) Buffer die zum gegebenen 128 Bit Digest passen. Der nächste Aufruf der Zufallsfunktion würde also ausgehend von 2^(8192 - 128) möglichen Seeds trotzdem nur EINEN gültigen benötigen damit der Angreifer die Zufallsfolge vorhersagen kann. Die Wahscheinlichkeit das als der Angreifer aus den 2^(8192 -128) möglichen Buffern zum aktuellen Digest den einen richtigen findet um daraus den nachfolgenden Zufallwert-Digest zu errechnen beträgt somit 1/2^(8192 -128). Aber, in der Zwischenzeit wurde ja der Buffer erneut mit Maus/Keyboard Koordinaten gefüttert. Diese Änderungen kann der Angreifer aber niemals 100%'tig simulieren, da jeder Mensch ganz individuelle Signaturen erzeugt.

D.h. es ist im kryptographischen Sinne nicht wichtig
1.) unvorhersagbaren Zufalls zu erzeugen, sondern man muß nicht reproduzierbaren Zufall benutzen
2.) mit enorm rießigen Datenmengen und Wahrscheinlichkeiten zu arbeiten, stattdessen muß man mit mathematisch beweisbaren Sicherheitsschranken rechnen können.

Eben diese beiden Gründe bedingen die Anwendung einer Hashfunktion, da genau sie es ist die das Verfahren mathematsich logisch absichert und beweisbar macht.

In kurz:
Unser Buffer ist 8192 Bits groß. Die Hashfunktion mappt alle diese 8192 Bits in einen Digitalen Wert von 128 Bits. Dieses Mapping ist derart das es mit absoluter Gleichverteilung alle seine 2^128 möglichen Digests auf den Bereich der 2^8192 möglichen Inputs mappt. Man reduziert also die 8192 Bits auf 128 Bits die relativ eindeutig sind. Ausgehend vom einem 128 Bit Digest gibt es also 2^(8192-128) gleich wahrscheinlich mögliche Input Buffer, aber nur EINER von diesen ist der richtige. Die Hashfunktion stellt nun sicher das der Angreifer ALLE der möglichen Inputs berechnen MUSS um mit 100%'tiger Wahrscheinlichkeit den EINEN richtigen zu finden. Dies ist die oberste Schranke. Die untere Schranke ist das der Angreifer minimal 2^128 verschiedene Buffer durchprobieren muß. Aber alleine diese 2^128 möglichen Testfälle übersteigt die heutige Rechenpower. Zudem ist die Wahscheinlichkeit das einer der 2^128 Testfälle auch der eine Treffer ist nur 1/(8192-128). Exakt diese Aufwandsanalysen werden möglich weil die mathematischen Grundlagen der Hashfunktionen diese bedingen.

Das Neu-Einberechnen von individuellen Maus/Keyboardsignaturen in den Buffer stellt sicher das selbst wenn der Angreifer den EINEN richtigen Inputbuffer zum gegebenen 128 Bit Digest findet, er dennoch NICHT den nächsten 128 Bit Digest berechnen kann.

Dieses System kann VORRAUSGESAGT werden, ist aber NICHT reproduzierbar, da die nötigen Simulationsbedinungen nicht reproduzierbar sind.

Gruß Hagen

PS: wenn die reine Verwendung des Mouse/Keyboard Inputs die Programmierer-Lösung ist so ist das Einfügen der Hash Funktion die Lösung des Kryptoanalytiker's, Kryptologen's und Mathematiker's.

Hallo Hagen,

danke für Deine ausführliche Antwort !
ich berechne jetzt die Passwörter mit
result := Thash_md5.CalcString(st,nil,fmtMIME64);

als Füllstring nehme ich nun GUID und noch andere zufällige Daten (jedenfalls nicht reproduzierbare Daten).
Ich denke mal, das reicht für meine Zwecke.
Ich hoffe, der Einbezug von GUID ist akzeptabel ?
Wenn diese Weltweit eindeutig ist, dann sollte sie doch auch nicht reproduzierbar sein, oder ?
Aber schon interessant das ganze, auch wenn ich es sicherlich nochmal lesen muss um alles auch wirklich zu verstehen letztendlich