â€˜The period of generator Brent-xor4096s in Table I should be 2^4128 and not 2^131072.â€™ ]]>

http://www.number.com.pt/index.html

Thanks.

]]>Fastest PRNGs: If you really want all-out speed on a per-call basis and don’t care too much about speed on a per-bit basis, you can get a little extra speed by returning smaller numbers of bits out of the result. This is only efficient if the RNG in question naturally buffers up several results at a time, like a 2-tap LFIB or GFSR. Both of which are rather low quality, but you can insert a barrel shift to the LFIB operation to dramatically improve quality without really hurting speed.

Good and fast PRNGs: There are numerous good and fast PRNGs, but the one I usually prefer is Robert Jenkins small fast prng – it easily passes BigCrush and all similar tests, is significantly faster than MT19937, and it consists of only 4 32 bit integers using addition, xor, and barrel shifts. See it at http://www.burtleburtle.net/bob/rand/smallprng.html

Comments on preceding comments:

10. Johannes Baagoe: Preliminary results suggests it passes statistical tests with ease, but it’s not particularly fast as written. On my computer it is running slower than MT19937.

8. Witek: I am a fan of the ISAAC algorithm, but it has no relation to AES. Perhaps you are thinking of RC4, which it is distantly related to?

7. Rich: I agree that that is why things are that way, but I think that things should NOT be that way. There are RNGs as fast or faster than LCGs on either a per-call basis or a per-bit basis that produce substantially better results. This is especially true on low-end and embedded CPUs, where multiplication is often slow.

/* MWC on 16 32-bit integers with a 21-bit multiplier. The temporary

result with the multiplication never exceeds 53 bits, for implementation

in javascript Numbers (“double-precision 64-bit binary format IEEE 754”).

The multiplier, a = 1994205, is the highest 21-bit integer such that

p = a * 2 ^ (32 * 16) – 1 is a safe prime. The period is (p – 1) / 2

(the corresponding Germain prime), close to 2 ^ 532 */

#include

static uint32_t s[16] = { // anything goes, except all zeros

// the values here come from Marsaglia’s CD

0x7cc41d3fUL, 0x16b21330UL, 0x1c01fd2dUL, 0x5f107963UL,

0xc907f813UL, 0xf62527cdUL, 0x25e7af78UL, 0x6a0517c0UL,

0x1ce4593cUL, 0x86af293aUL, 0xcee31109UL, 0x429bf39bUL,

0xd0fc2b62UL, 0x0eb12482UL, 0xd677a3d8UL, 0x09313e9fUL

};

static uint32_t c = 0;

static uint8_t k = 0;

static inline uint32_t mwc16(void) {

uint64_t t;

k = (k + 1) & 15;

t = 1994205 * (uint64_t) s[k] + c;

c = t >> 32;

return s[k] = t;

}

That was my reasoning in implementing my own libc. I actually just used the ISO C sample implementation because it’s a one-liner. :)

]]>> Correct, but now you have the problem of selecting a password/seed.

For crypto yes but not for other puproses like some scientific simulation, for that seed=0, seed++ or time() should be fine.

> That Mersene twister is not cryptographically secure is not a secret. It is warned that you

> should run its output through a hash or crypto function (for hash this kinda makes sense, for

> crypto itâ€™s probably better to do what you said since itâ€™s faster).

You would also have to find a new way to initialize the twister, the currently standard 32bit seed + LCG is very bruteforceable.

Besides what point is there in using MT at all when you use a secure hash or crypto function anyway …

> Merseneâ€™s strength is its

> very long period (thereâ€™s an implementation with period 2^19937-1), however I donâ€™t know how

> the others compare or if itâ€™s Mersene-specific.

looking at testu01, DX-1597-2-7 has a period of 2^49507 and brent-xor-4096s has one of 2^131072, both are faster than MT19937 according to testu01 and both also pass all tests of testu01 while MT19937 does not.

Beside this, IMHO what difference does it make if you have a 2^19937 or a 2^200 period PRNG? you are not going to be able to take enough samples to notice the difference anyway …

Correct, but now you have the problem of selecting a password/seed.

That Mersene twister is not cryptographically secure is not a secret. It is warned that you should run its output through a hash or crypto function (for hash this kinda makes sense, for crypto it’s probably better to do what you said since it’s faster). Mersene’s strength is its very long period (there’s an implementation with period 2^19937-1), however I don’t know how the others compare or if it’s Mersene-specific.

]]>> >

> > â€œAnythingâ€ based on AES, SHA-1, MD5, â€¦

> So hash function is the best random number generator?

IMHO, if its (lack of) speed is ok then yes.

The reason why, is simply that these cryptographic functions have been heavily tested to be free of any practical way to predict the cleartext/password from their output.

Thus when a AES(i++ (cleartext), seed (password)) would be found to be different from random data in some test or simulation, that effectively would leak information about the cleartext, that is it being i++ instead of truely random. This thus would be a weakness in AES.