Drawbacks of multiple sources of entropy for AES

Niels

1/14/24, 8:41 PM

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.

1 + 2

aes-gcm

Eugene Styer

1/14/24, 10:32 PM

Related/duplicate: https://crypto.stackexchange.com/questions/17658/mixing-entropy-sources-by-xor?rq=1

Swashbuckler

1/15/24, 6:06 PM

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.

Score:1

Crypto

mentallurg

1/15/24, 8:47 AM

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.

+ 3

Niels

1/15/24, 1:38 PM

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

mentallurg

1/15/24, 2:31 PM

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](https://security.stackexchange.com/questions/195515/is-rdrand-used-in-a-safe-way-by-windows-10).

Niels

1/15/24, 6:29 PM

Makes sense I guess

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Drawbacks of multiple sources of entropy for AES

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.