John Reagan

2017-03-31 15:31:26 UTC

It is Friday and I'm in a good mood. I figured I'll toss something out for a friendly discussion.

For Alpha and Itanium, the MATH$RANDOMxxx functions use exactly the same algorithm as VAX. Is is a rather simple piece of code that is pseudo-random. If you have them the same seed value, you'll get the same sequence over and over. Of course some of you compute your initial seed with some randomness (time of day, bits out of some system cell, a hash of the tweets by the President, etc.) that at least makes you get different sequences on different runs.

For x86-64, recent chips have real random number generators,

7.3.17.1 RDRAND

The RDRAND instruction returns a random number. All Intel processors that

support the RDRAND instruction indicate the availability of the RDRAND

instruction via reporting CPUID.01H:ECX.RDRAND[bit 30] = 1.

RDRAND returns random numbers that are supplied by a cryptographically secure,

deterministic random bit generator DRBG. The DRBG is designed to meet the NIST

SP 800-90A standard. The DRBG is re-seeded frequently from an on-chip

non-deterministic entropy source to guarantee data returned by RDRAND is statistically uniform, nonperiodic and non-deterministic.

7.3.17.2 RDSEED

The RDSEED instruction returns a random number. All Intel processors that

support the RDSEED instruction indicate the availability of the RDSEED

instruction via reporting CPUID.(EAX=07H, ECX=0H):EBX.RDSEED[bit 18] = 1.

RDSEED returns random numbers that are supplied by a cryptographically secure,

enhanced non-deterministic random bit generator (Enhanced NRBG). The NRBG is

designed to meet the NIST SP 800-90B and NIST SP800-90C

standards.

So should we switch MTH$RANDOM/MATH$RANDOM to use the on-chip, much-better, random number generator RDSEED? The downside is that even if start with the same seed value (we'd essentially ignore the seed value), you'll get different sequences every single time. We'll still have to extract bits to form the floating result of course.

For reference, here's the current algorithm:

28 ** Abstract:

29 **

30 ** This file is used to generate object modules for vms_rand.

31 ** The interface is: F_TYPE y = vms_rand(unsigned int *seed).

32 **

33 ** The routine updates seed with

34 ** seed = (69069 * seed + 1) mod (2 ^ 32)

35 ** and then uses the high order bits to form a floating

36 ** point value. The goal of this routine is compatibility

37 ** with the VAX/VMS mth$random routine.

For Alpha and Itanium, the MATH$RANDOMxxx functions use exactly the same algorithm as VAX. Is is a rather simple piece of code that is pseudo-random. If you have them the same seed value, you'll get the same sequence over and over. Of course some of you compute your initial seed with some randomness (time of day, bits out of some system cell, a hash of the tweets by the President, etc.) that at least makes you get different sequences on different runs.

For x86-64, recent chips have real random number generators,

7.3.17.1 RDRAND

The RDRAND instruction returns a random number. All Intel processors that

support the RDRAND instruction indicate the availability of the RDRAND

instruction via reporting CPUID.01H:ECX.RDRAND[bit 30] = 1.

RDRAND returns random numbers that are supplied by a cryptographically secure,

deterministic random bit generator DRBG. The DRBG is designed to meet the NIST

SP 800-90A standard. The DRBG is re-seeded frequently from an on-chip

non-deterministic entropy source to guarantee data returned by RDRAND is statistically uniform, nonperiodic and non-deterministic.

7.3.17.2 RDSEED

The RDSEED instruction returns a random number. All Intel processors that

support the RDSEED instruction indicate the availability of the RDSEED

instruction via reporting CPUID.(EAX=07H, ECX=0H):EBX.RDSEED[bit 18] = 1.

RDSEED returns random numbers that are supplied by a cryptographically secure,

enhanced non-deterministic random bit generator (Enhanced NRBG). The NRBG is

designed to meet the NIST SP 800-90B and NIST SP800-90C

standards.

So should we switch MTH$RANDOM/MATH$RANDOM to use the on-chip, much-better, random number generator RDSEED? The downside is that even if start with the same seed value (we'd essentially ignore the seed value), you'll get different sequences every single time. We'll still have to extract bits to form the floating result of course.

For reference, here's the current algorithm:

28 ** Abstract:

29 **

30 ** This file is used to generate object modules for vms_rand.

31 ** The interface is: F_TYPE y = vms_rand(unsigned int *seed).

32 **

33 ** The routine updates seed with

34 ** seed = (69069 * seed + 1) mod (2 ^ 32)

35 ** and then uses the high order bits to form a floating

36 ** point value. The goal of this routine is compatibility

37 ** with the VAX/VMS mth$random routine.