6
$\begingroup$

Even at a high consumption rate of 100,000 generations per second, it would take decades to exhaust the NIST recommended reseed interval of 2**48 invocations of DRBG _generate(). Should one even care to reseed? (REF: NIST SP 800-90A, Rev 1.0)

$\endgroup$
  • 1
    $\begingroup$ If you don't reseed and your state gets leaked, all other outputs can be computed from that. If you do re-seed only all outputs after the last reseed can be computed. $\endgroup$ – SEJPM Feb 12 '17 at 20:49
  • $\begingroup$ What if my generate function is computed in a secure hardware environment, which is impervious to SW attacks? $\endgroup$ – user13311 Feb 12 '17 at 20:54
  • 2
    $\begingroup$ Your secure hardware environment probably also provides a high-performance RNG (SGX+RDRAND?) so now you don't need to worry about NIST 800-90 unless you really need the determinism. $\endgroup$ – Thomas M. DuBuisson Feb 12 '17 at 20:58
  • 1
    $\begingroup$ It always depends on your exact thread model. If you have secured hardware, there may be other attacks applying to you. Maybe your device is deployed in the wild. Maybe people try really hard to recover the state a non-intrusive way. Maybe they apply DPA (which is a really strong attack) and your secure hardware wasn't prepared for that. Maybe they find a new flaw in your secure hardware. As I said: It really depends on your threat model, but re-seeding usually doesn't hurt. $\endgroup$ – SEJPM Feb 12 '17 at 20:58
  • $\begingroup$ (OP here). In this case, we have a secure computing hardware, without an RNG or a source of true randomness within. But, agree with the comment on the possibility of physical attacks with DPA in insecure deployments. Not an issue for large scale infrastructure deployments, but will be, for small and remote deployments, where physical security of the server/system/motherboard can not be taken for granted. $\endgroup$ – user13311 Feb 13 '17 at 5:49
4
$\begingroup$

As usual, the answer is: it depends.

It mainly depends on two factors:

  • Do you have a source of entropy and how good is it?
  • What's your environment and your threat model?

The benefit of re-seeding your DRBG should be clear: If the state of your DRBG gets compromised at any point, an attacker can re-compute all the outputs of the DRBG following up until the last reseed which limits the damage in case of an successful attack.

Now for the question you may have: Can a re-seed hurt security? No, it can't because information from the last DRBG state is included, transferring initial entropy into the new state and adding new entropy.

So for the first point: Assume you have a good RNG, then re-seeding as often as possible is a good idea that highly limits the risk associated with a state-compromise. If you however have a bad RNG or none at all, you could still try to re-seed, but then it's also a question of the effort involved in doing the re-seed and whether this effort is worth the minimal gain.

Now for the second point: The threat model. This really is your answer to the question: "what access to my device(s) does the attacker have?". If you have secure hardware for the DRBG and an attacker can at most get software-level access or only have a remote view, chances are that a state-compromise won't happen. If the attacker however can get hands-on with the device and try all their best in extracting the state (as you'd be able to with a stolen smart card for example), then advanced attacks like DPA need consideration. If you're sure that such advanced attacks aren't realistic (because breaking the RNG wouldn't outweigh the cost of developing and deploying these attacks), then you can go without a re-seed. If an attacker has a motivation to try really hard to get into the device they'll probably try all those attacks and depending on how good the secured hardware is, chances are they'll succeed.

| improve this answer | |
$\endgroup$
  • $\begingroup$ Agree with all observations above. The threat model evolves with the deployment model. A smart card, phone or a mobile client is easily subject to DPA through physical access. Versus, a server in a large data center with enforced perimeter security, authorized access and audits is hard to be probed for DPA, unless we are talking of espionage of highly resourced agencies. The threat level again raises, when the deployment comprises of rented space, as say, the top of buildings and other public places. It is interesting that NIST has no guidance on reseeding as applicable to threat levels. $\endgroup$ – user13311 Feb 13 '17 at 16:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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