6
$\begingroup$

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
Improve this question
$\endgroup$
1
  • $\begingroup$ 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. $\endgroup$
    – engineerC
    Commented Dec 16, 2012 at 19:51

1 Answer 1

Reset to default
13
$\begingroup$

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.

Improve this answer
$\endgroup$
6
  • $\begingroup$ Added some information $\endgroup$
    – tonyk
    Commented Dec 16, 2012 at 20:16
  • $\begingroup$ "In particular if the seed is longer than 128 bytes it becomes totally insecure" why ? $\endgroup$
    – Alexandre Yamajako
    Commented Dec 17, 2012 at 22:56
  • 5
    $\begingroup$ @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. $\endgroup$
    – Ilmari Karonen
    Commented Dec 18, 2012 at 9:04
  • $\begingroup$ @IlmariKaronen: Why shows why you should never roll your own crypto algorithm. $\endgroup$
    – David Schwartz
    Commented Dec 18, 2012 at 10:39
  • $\begingroup$ Good point, I forgot about the key reduction step $\endgroup$
    – Alexandre Yamajako
    Commented Dec 18, 2012 at 13:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.