Take the 2-minute tour ×
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It's 100% free, no registration required.

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.

Edit - More info:

  • 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
share|improve this question

migrated from stackoverflow.com Dec 17 '12 at 21:40

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

2 Answers 2

up vote 8 down vote accepted

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.

share|improve this answer
    
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
4  
@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

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.

share|improve this answer
    
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

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.