Ja must du. Alles andere wäre auch falsch vom Konzept der Library her.
Neueste Version von Luckie's Server:
Delphi-Quellcode:
uses NInts, DECRandom, DECUtils;
procedure Test;
var
A: IInteger;
begin
NRnd(A, 512); // 512 Bit Zufall erzeugen, 2^512 <= A < 2^513
end;
initialization
// a.)
RandomSeed; // randomisiert den installierten RNG mit Systemtimer !
// b.)
randomSeed(Daten, SizeOf(Datan)); // mit eigenen Daten
finalization
end.
Wichtig ist das
Unit DECRandom eingebunden wurde um einen sicheren YARROW Zufallsgenerator zu initialisieren. Falls dies nicht erfolgte so benutzen die Funktionen in DECUtls.pas eine Abart des LCGs von Borland (unsicher).
Bei Programstart sollte nun dieser RNG randomisiert werden. Man kann den einfachen aber unsicheren Weg gehen indem man RandomSeed() ohne Paramater aufruft. Dann wird intern der RNG per Systemzeit initialisiert, also so wie es Randomize() im Borland RNG macht.
Oder man geht den sicheren Weg und erzeugt seine eigenen Seed Daten die dann sicher sein können. Diese sollten mehr als 128 Bit haben und eben sicher sein. Das bedeutet nicht reproduzierbar aber auch nicht echt zufällig sondern beweisbar sicher zufällig für den Angreifer.
Es hängt also davon ab WAS du mit den Zufallsdaten später machen möchtest. Einfache Statistiken brauchen keinen sicheren Zufall, probalistische Verfahren benötigen keinen sicheren Zufall. Aber kryptographische Systeme wie die Schlüsselerzeugungen beim RSA benötigen unbedingt einen sicheren Zufall. Die Systemzeit als Seed wäre damit absolut unsicher. Ein Angreifer könnte Pi*Daumen abschätzen wann ein Schlüssel erzeugt wurde und dann mit dem gleichen und bekannten Verfahren wie im
DEC diesen Zufall reproduzieren.
Als sehr einfach und denoch sicher hat sich die Methode herausgestellt das man den Anwender einfach wahllos par Tasten drücken läst, oder die Maus parmal hin&her bewegen lässt. Diese Daten werden gesammelt und RandomSeed() als Daten übergeben.
Verwendet man heutzutage solche mathematisch sicheren Algorithmen, mit einer Library die technisch einwandfrei ist, so bleiben dem Angreifer nur 2 Angriffspunkte real übrig. Erstens die Brute Force Attacke deren Schranken aber so hoch gewählt wurden das sie absolut unpraktikabel ist. Und zweitens der Zufallsgenerator, denn zu jeder Zeit wird in der Kryptographie immer wieder Zufall benötigt. Ist also der RNG schlecht so stellt das eine theoretische Möglichkeit eines Angriffes dar.
Der in DECRandom enthalten RNG ist ein YARROW typischer Vertreter (YARROW = Bruce Schneier). Er arbeitet auf Basis der SHA1 secure Hash Funktion auf einem interen Register mit 1024 Bits Größe und einem 32 Bit Counter. Dh. bei jedem Aufruf zur Erzeugung 1 Bytes wird dieser Counter + 128 Bytes Register gehasht und der Hash Digest[1] als Resultat zurückgegeben. Vorher wird aber das 128 Bytes register aktualisiert=modifiziert mit FRegister[Counter mod 128] := FRegister[Counter mod 128] xor Hash.Digest[0];
Das bedeutet:
- es können 2^32 Bytes ohne Wiederholungen erzeugt werden bei gleichen Seedwerten. Dies Periode ist garantiert aber nicht die unterste Grenze für eine Wiederholung.
- die maximale Periode beträgt 2^1024 Bits auf Grund des Registers und der Hashfunktion.
- die Sichheitsrelevante Periode beträgt 2^(160+32) Bits auf Grund der Sichheirheit der hashfunktion (SHA1 = 160 Bits) und dem 32 Bit Counter.
- das Interne Register wird demzufolge alle 128 Aufrufe komplett modizifiert worden sein.
- um diesen RNG zu benutzen muß nur DECRandom in die Uses Klausel geschrieben werden.
- die Aktualisierung des Register ist algorithmisch getrennt vom erzeugten Zufall. Weil zur Modifikation des FRegister der Hash.Digest[0] benutzt wird und für das Zufallsresultat Hash.Digest[1]. Die SHA1 Funktion stellt algorithmisch sicher das diese beiden Bytes zueinander nur indirekt aber zwangsläufig direkt abhängig von dem 1024 Bit Register ist. Das ist quasi die Wirkungsweise jeder sicheren Hashfunktion.
Gruß Hagen