Hallo,
die Funktion @rnd() von XProfan generiert eine Pseudo-Zufallszahl, die allerdings für kryptographische Anwendungen unbrauchbar ist. Das gilt schon für die deterministische Natur des Generators an sich, insbesondere aber dafür, dass @set("randseed",x) nur 65535 Startwerte zulässt, was nach heutigen Maßstäben geradezu lächerlich wenig ist. Schon dass Seeden eines PRNG nur mit dem vollen Long-Wert der Millisekunden seit dem letzten Systemstart gilt als sträflich nachlässig.
Moderne Windows-Systeme bringen eine API-Funktion mit, die hier Abhilfe schafft. Zum Beispiel, wenn man sichere Passwörter aus echten Zufallszahlen generieren möchte. Fast jede moderne CPU besitzt einen "Noise-Chip", der echte Zufallszahlen generiert. Hierauf greift die Windows-Funktion zu, und wohl auch noch auf andere Entropiequellen aus dem System.
Hier die XProfan-Funktion, um hieraus eine echte Zufallszahl zu generieren:
PROC GetSystemRandomNumber 'generiert eine Byte-Zufallszahl zwischen 0 und endnumber&-1 über den Windows-Zufallszahlengenerator (Rückgabe von -1=Fehler)
parameters endnumber&
declare b#,erg&,r&,f!
if %pcount=0
endnumber&=256
endif
if endnumber&>256
endnumber&=256
elseif endnumber&<2
endnumber&=2
endif
dim b#,2 'muss ein Word fassen, siehe unten
erg&=@external("Bcrypt.dll","BCryptGenRandom",0,b#,2,2) 'letzter Parameter: 2=~BCRYPT_USE_SYSTEM_PREFERRED_RNG; vorletzter Parameter=Puffergröße, weist die Funktion an, zwei Zufalls-Bytes (also ein Zufalls-Word) zurückzugeben
if erg&<>0 'Fehler
r&=-1
else
if endnumber&=256
'direkt erste generierte Zufallszahl zwischen 0 und 255 übernehmen
r&=@byte(b#,0)
else
'generierte Zufallszahl zwischen 0 und 65535 auf Bereich zwischen 0 und endnumber&-1 mappen
'hierzu brauchen wir ein Zufalls-Word, weil bei einem Byte bei bestimmten Endnumbers manche Zahlen deutlich bevorzugt würden, weil mindestens eine mehr aus dem 255er-Feld nach dem Int zu ihnen werden als bei anderen Zahlen
'das hingegen ist bei 65535 Zahlen, die auf maximal 0-254 gemappt werden, zu vernachlässigen
'ein Long wiederum wäre grundsätzlich noch besser, geht aber nicht, weil es in XProfan signed ist, wir aber nur positive Zahlen erhalten wollen (mit Quad ab XProfan X2 ist es dasselbe)
r&=@word(b#,0)
while r&=$FFFF 'nicht $FFFF, weil dann das Ergebnis =endnumber& wäre, nicht kleiner --> also neue Zufallszahl generieren
erg&=@external("Bcrypt.dll","BCryptGenRandom",0,b#,2,2)
if erg&<>0 'Fehler
r&=-1
break
else
r&=@word(b#,0)
endif
endwhile
if r&<>-1
f!=r&/$FFFF
f!=f!*endnumber&
r&=@int(f!)
endif
endif
endif
dispose b#
return r&
ENDPROC 'GetSystemRandomNumberBeste Grüße, Jens-Arne
Wer's noch individueller und unabhängig vom System und von Microsoft haben will (nur Rezept, kein Code):
- Foto mit viel Entropie aufnehmen (z.B. Baumlaub im Wind)
- hieraus, sagen wir, 10000 Farbwerte nehmen (enthält reichlich genug Entropie)
- über den Speicherbereich, in dem diese Werte stehen, den SHA256-Algorithmus laufen lassen
- schon hat man 32 exzellente echte Zufallsbytes an der Hand
- ggf. mit den nächsten 10000 Farbwerten wiederholen etc. pp.
- Foto sofort löschen (es soll ja niemand sonst den Seed der Zufallszahlen kennen)