5 ms·
Summarizing, the paper suggests that you can generate high quality pseudorandom numbers by hashing a counter with a cryptographic hash (such as AES). Since AES
by nkurz 11y ago
Summarizing, the paper suggests that you can generate high quality pseudorandom numbers by hashing a counter with a cryptographic hash (such as AES). Since AES has hardware support in modern processors, this is fast: less than 2 cycles per byte of randomness. If you do fewer "rounds" of encryption than used for cryptography, you can pass all existing tests for randomness with run time of less than 1 cycle per byte. Using a counter as the state makes it very easy to skip ahead in the sequence, and to distribute "streams" across multiple processors.
- deleted 11y ago[deleted]
- mistercow 11y agoI'm sort of surprised this could be a paper published in 2011. Isn't this pretty much the obvious thing to do? Counter hashing is a well known way to generate good random numbers, and it seems almost as obvious how you'd scale to multiple processors.
- deleted 11y ago[deleted]
- gruez 11y agoYeah, considering what was described is essentially aes-ctr
- meric 11y agoForgive my ignorance in cryptography. If a series of pseudorandom numbers can be trivially replicated by figuring out the counter and hash algorithm (seems simple with open source software), how can the psuedorandom numbers be said to be of high quality?
- lenish 11y agoThe key(s) used for the cipher would need to be randomly seeded in some way that an attacker could not easily guess (e.g. with a different CSPRNG). Edit: And for hash functions, you can generate some random bytes that you append the counter to before putting it through the hash algorithm. The same as above, if those bytes are hard to guess then the construction should be safe.