3

I have a source which generates secrets at $8-10 bits $ per second. I need to use this secret to feed another generator every second. I am wondering how long should I wait while I am concatenating 8 bits every second and then use longer bits as input to hash.

I have two options:

  1. Use 8 bit that I get every second, hash it and send to next level every second.

  2. Wait for say 10 seconds then hash the final say 100 bit. In between for 9 seconds keep sending hashed value of previous 100 bit using public informations.

Which one is more secure? I am using HKDF for hashing.

Community
  • 1
Jay
  • 195
  • 11

2 Answers2

10

You should aggregate bits until you have enough seed bits to start your DRBG using an initial seed. Your seed should contain at least 128 bits of entropy (the amount of uncertainty to an attacker).

Then you could either add the bits as additional seed when you get it or you could first aggregate some entropy. With only an update rate of about 8 bits per second you might as well directly add the entropy to your DRBG.

To create the same pseudorandom bit stream on both sides you should:

  1. make sure you got the same algorithm on both sides;
  2. configure the DRBG identically on both sides;
  3. update your entropy at exactly the same time;
  4. request data from the DRBG using the same methods and parameters.

Note that HKDF is not a pseudo random number generator (PRNG) or deterministic random bit generator (DRBG, same thing). It may be a pseudo random function but that's not the same.

HKDF turns an already secure key into more key material, possibly given additional information. HKDF / HMAC could be used to build a deterministic random bit generator. If you want to do that then you need to create a paper and prove it is correct.

I would recommend having a look at NIST SP 800-90A (revision 1) and pick a DRBG from there.

Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
5

There are three classes of random number generators (my own informal classes), dependant on the relative entropies that flow in and out:-

  • Class 1. Hout < Hin, which is a true random number generator (the most secure and best) such as those by Swiss company ID Quantique. This is the class of generator that can be used for creating one time pad material.

  • Class 2. Hout > Hin, the most common commercial type like ultra fast beam splitters and ostensibly /dev/random.

  • Class 3. Hout >> Hin, which is a reseeded psuedo random number generator like /dev/urandom.

where H is the entropy.

Let's try and make a Class 1 type which is the most pure and secure.

  1. Capture 1MB from your entropy source over 28 hours. Why rush?
  2. Aquire a good compression tool like fp8.exe.
  3. Compress the entropy sample, divide by two for safety and you have a very good estimate of usable cryptographic entropy rate from the source. This step is CRUCIAL in determining the entropy rate. Do not try to use the fancy Shannon formula as it won't work if there is any auto correlation in the entropy stream.
  4. I'm unfamiliar with the input width to HKDF, but simply divide it by your generation rate and that's the time between re seeding.
  5. You don't need the PRNG. The HKDF whilst exorbitant, will act perfectly as an entropy extractor.

As an example, if you're using SHA-256 it would need 256 bits of entropy as an input. If your raw entropy rate is 10 bits /s, it might be say 4 when you measure it using my technique. So feed SHA-256 every 64 seconds.

64 seconds will create a class one generator which is a true random number generator. Reducing the feed rate will reduce the security and you will have a class two which might be acceptable to you.

PS. I find it a bad idea to use a cryptographic function as a randomness extractor. It's mathematically unnecessary and dangerous in that if the entropy source misbehaves or you've underestimated the entropy generator rate, you'll never know. If you use a much simpler randomness extractor such as a compression function /matrix, any mistake you've made will immediately become obvious in the quality of the final output. HDKF will continue to produce uniformly distributed random numbers with any kind of rubbish input and you'll never know which class the generator is running within.

PPS. Don't follow any of the NIST guidance. It's specifically crippled to preclude the creation of true random number generators and therefore not as secure as it could be. Unfortunately (but not unexpectedly) you will find a heavy bias towards NIST on this forum. If you need further guidance, look to Europe like AIS or ISO standards. Maybe the French too :-(

Paul Uszak
  • 15,905
  • 2
  • 32
  • 83