Re: OT: RFC, PRNG


"Josiah Carlson" <josiah.carlson@xxxxxxxxxxxxx> wrote in message
news:wGH6i.23349$YL5.10218@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
cr88192 wrote:
"Josiah Carlson" <josiah.carlson@xxxxxxxxxxxxx> wrote in message
To guarantee that we never get two _ in a row, we alternate between
choosing encodings forwards or backwards through the symbol list. Some
outputs:

Qcdq2hWWhT3WrV9
QMir2hWWhT3WrV9
Qsos2hWWhT3WrV9
Qctt2hWWhT3WrV9
QMyu2hWWhT3WrV9
QcdS2i9WST3WrV9
QMiT2i9WST3WrV9
QsoU2i9WST3WrV9
QctV2i9WST3WrV9
QMyW2i9WST3WrV9


dunno...

What don't you know about? The symbol is encoded directly from process
id, the current time in seconds, and the number of times the function has
been called in the last second. If you had a program that closed and was
restarted within 1 second that just happened to get the same pid, you
could get duplicate entries. This may or may not be an issue, but it
could easily be handled by fetching a few more bits from the underlying
processor performance counters, and/or using a few more bits from the time
(another 8 bits would get you 4ms resolution between restarts).


potentially, but I like my approach more...
(less complicated).

also, with 96 bits, the probability of clashes is very low, in any case
(just assuming the RNG is working anywhere near as good as assumed).

here are a few outputs (several runs of the app):
AUipRPOttkFqMPPMCv
LJPIwaKicvAvHWoPOM
DfAjWQOWdxntHcTWSD
FiGmhIEgSNMBGRjspR

BsnexRAChlbuPpPEGO
OdoHWkNFAXeLOUrvil
PvhjRKHdgcjUCrafiC
PCkhFSBimWDRMpEojx

FHOXwaGPXgluGqMbnB
GTdhjFGNJDbVOqCGgf
EodSxiPaRAWcAmgckf
KXiBONAMJQlcCpPSSM

and the contents from the current random bits file (changes each run):
E76B7AA9 710BEDFF 4E4D7DB9 E72ED011 445380DA 7FF5D34F 53E8AC35 C193FD2B
A5805BE7 A962D8AE EBE4838B B128314E CFF4474C 17FC1A43 B27E606C EB0550CB
8B7C9BAB 6F5E9CC2 1637C00E 72C9F545 3B7068BC ED2693CC AE8AB1E3 77C34968
44F7AC1F A19CBD93 45655551 4461C0E7 BF2D34B3 010D82A4 72DA59C1 9EF6850F
349E56C8 41819353 BCBC8A97 7B8BC1D2 84A374A7 AF148F0E 4CDA3D68 BC9FCAD9
BD7D25A2 0B4DF618 4C87EC13 701D30EB 9F35FBF3 A7C986CB B1FD6303 F52BA534
47A71ED1 EC076A9C 962CFB6A 2EC7FBCB 3E13CEF0 2BC79B01 0A4F6F58 D4B168C1
F25BF1F8 BE957F7A 54B8068E 0FC6CB0F DE69B20A A9D928E3 352B1F9A 02139C8A
7D64F4F9 9C100C20 E7306AAB DED5BCCF AE49AFEF 799DCF41 AF031C54 DB25A391
CC5DADF8 B47C318C 9E46879D 417B46FD 70C559A9 BE192773 03FA56AC 1B01A009
0AF1A959 0530D2C7 84EC2001 562CB84B ABAD5E14 4EECDE64 3E848A67 E0A3AF32
859B54C1 80A80186 77AF9DB7 9A6D389B 2C352F58 983B5A72 6EF91461 93C9F738
4E6467BA CFD8B58C 87D9F5A7 FFE2B265 B41CD34B 459BEB63 D7413B3D 9E6B789D
30514C07 774495FE 98FA1C88 25E1E351 AB159F99 99562B62 2F563BCD 75C07E64
981DAC1E C261A1B4 3DFC73B1 D1E6C96C 7CE748AD F720270E AC2C1FFD 09681A16
8CFCBAB2 77E42E01 27A31548 C2BB743B 0B3FA4AB FBF1ACF6 E9CE9B7D E8631F89


oh well, sadly thus far I have not yet tried running any of this through any
statistical checks (or even the 'testing for compressibility' check), so
yeah...



- Josiah


.