Good enough deterministic PRNG based on hashes

Lets say I have a seed named iv which has a decent amount of entropy.

Are there any glaring issues with the following?

First 64 bytes are generated by SHA512(iv)
Next 64 bytes are generated by HMAC_SHA512(iv, Previous64Bytes)
and so on...

Obviously if I needed "perfect" security I could use something like HMAC-DRBG (NIST SP 800-90), but I need something that's good enough, easy to implement and I do not care if a supercomputer breaks it in 10 years.

• This will not be used to generate more than 500 bytes of data per run
• The implementation will be out in the open (javascript)
• Speed of the algorithm doesn't matter
-

migrated from stackoverflow.comDec 17 '12 at 21:40

This question came from our site for professional and enthusiast programmers.

A deterministic PRNG is pretty much the same thing as a stream cipher. So you could go with AES-CTR or AES-OFB where available. They're standard, and are much faster than all these HMAC-SHA-512 based constructions.

But if you really want to use a hash, then I'd go with the similar HKDF construction:

Extraction Step:

PRK = HMAC-SHA512("", seed)

Expansion step:

T(0) = empty string (zero length)
T(1) = HMAC-Hash(PRK, T(0) | info | 0x01)
T(2) = HMAC-Hash(PRK, T(1) | info | 0x02)
T(3) = HMAC-Hash(PRK, T(2) | info | 0x03)

Where info is some string describing the purpose of your output(can be empty if you don't use a single PRK for more than one purpose), and you output T(0) | T(1) | T(2) | ...

The standard HKDF only uses a single byte, but if you need longer output, you could use a larger counter, such as a four byte integer.

With your construction, using plain SHA-512 for the first step, and HMAC-SHA-512 for the other steps is problematic. In particular if the seed is longer than 128 bytes it becomes totally insecure. Use HMAC for all steps.

If you use HMAC for every step, your construction essentially becomes OFB mode, except that you use a keyed hash instead of a block cipher.

-
Added some information –  tonyk Dec 16 '12 at 20:16
"In particular if the seed is longer than 128 bytes it becomes totally insecure" why ? –  Alexandre Yamajako Dec 17 '12 at 22:56
@Alexandre: According to the HMAC specification, if the given key is longer than the input block size of the hash, it is first reduced by hashing it with the plain hash. The input block size of SHA-512 is 128 bytes, so if the key $K$ is longer than that, $\text{HMAC-SHA512}(K,X)=\text{HMAC-SHA512}(\text{SHA512}(K),X)$, and thus the first 64 bytes of tonyk's construction will directly leak the effective MAC key. –  Ilmari Karonen Dec 18 '12 at 9:04
@IlmariKaronen: Why shows why you should never roll your own crypto algorithm. –  David Schwartz Dec 18 '12 at 10:39
Good point, I forgot about the key reduction step –  Alexandre Yamajako Dec 18 '12 at 13:30
show 1 more comment

Well, you're just using a homebrew pseudo-random generator. I would be very hesitant to use such a thing for cryptographic purposes; just because it "looks" random doesn't mean it is, it may be possible to predict future output based on past output, etc., etc. Not knowing your application requirements or computing constraints I couldn't recommend anything different.

If you're determined to use something like this, you should probably ask in crypto stack exchange.

-
Voted down because, although it is good advice, it is not an answer. –  owlstead Dec 17 '12 at 0:39
If that's the case, you should probably flag it instead. –  Joe Z. Dec 26 '12 at 22:54