1
$\begingroup$

Since AES needs IV to be random (unless fed by a unit test), I was wondering how to properly handle it.

I know that Intel/AMD now supports the rdrand64 function but I don't fully want to rely on that.

Can I safely combine multiple sources of randomness and SHA256 them to produce a random 256-bit number?

My sources of randomness will be: time in ns, clock from rdtsc instruction, BCryptGenRandom (for windows, with /dev/random probably for linux) and a constantly increasing counter. I think this should make it pretty much uniformly random, or is there a drawback that I'm not seeing here?

Edit: and of course, the rdrand64 would also be included if available.

Improve this question
$\endgroup$
2
  • $\begingroup$ Related/duplicate: crypto.stackexchange.com/questions/17658/… $\endgroup$
    – Eugene Styer
    Jan 14 at 22:32
  • $\begingroup$ Time, even at the nanosecond level, is a very poor source of entropy,even assuming the timer you're using can measure individual nanoseconds. In a million years of nanoseconds there's only a little over 56 bits of entropy. In a more realistic time space of about 10 years there's only about 24 bits of entropy. $\endgroup$
    – Swashbuckler
    Jan 15 at 18:06

1 Answer 1

Reset to default
1
$\begingroup$

When you use AES GCM, the main requirement for IV is that each IV should not be reused. Also NIST SP 800-38D requires that:

... if the key generation mechanism is deterministic, then the management of the mechanism shall provide strong assurance that no outside entity can induce the repetition of a previous set of inputs to the mechanism...

In your scheme:

  • "time in ns": System time can be reset or even set to particular value.
  • "clock from rdtsc instruction": It is reset each time the computer is restarted.

But it is not bad, because you don't need them at all.

You are going to use BCryptGenRandom for Windows and /dev/random for Linux, and this alone is sufficient.

Improve this answer
$\endgroup$
3
  • $\begingroup$ But as long as one of the inputs is random then the sha should return a different value right? So even if you could change any of them, that'd not change much right? Do these functions also use the rdrand64 instruction or should I add this and sha256? Edit: I'm talking about appending them into 1 buffer and sha-ing the buffer, not just xoring them $\endgroup$
    – Niels
    Jan 15 at 13:38
  • $\begingroup$ Linux does already use rdrand64 as an additional factor for /dev/rand. Thus adding it makes not much sense. It is not known, if BCryptGenRandom uses it. But if the claim of Microsoft about compliance with NIST SP800-90 is true, then adding rdrand64 is not necessary. See also this thread. $\endgroup$
    – mentallurg
    Jan 15 at 14:31
  • $\begingroup$ Makes sense I guess $\endgroup$
    – Niels
    Jan 15 at 18:29

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.