1

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.

mentallurg
  • 2,611
  • 1
  • 16
  • 22
Niels
  • 23
  • 3
  • Related/duplicate: https://crypto.stackexchange.com/questions/17658/mixing-entropy-sources-by-xor?rq=1 – Eugene Styer Jan 14 '23 at 22:32
  • 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. – Swashbuckler Jan 15 '23 at 18:06

1 Answers1

1

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.

mentallurg
  • 2,611
  • 1
  • 16
  • 22
  • 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 – Niels Jan 15 '23 at 13:38
  • 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. – mentallurg Jan 15 '23 at 14:31
  • Makes sense I guess – Niels Jan 15 '23 at 18:29