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,661
  • 1
  • 17
  • 24
Niels
  • 23
  • 3

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,661
  • 1
  • 17
  • 24