[kurikuri]

Keeping the DRBG’s state (seed material) secure for the duration of its use is the problem. If this state is leaked, depending on the type of leak, then anything generated from that DRBG is now not protected. Even worse, you may not even know that this the case and continue to use the DRBG assuming that it is safe.

If state management is was not an issue, I’d agree with you, but the fact that vulnerabilities tend to appear in very unexpected places (side channels, speculative execution, etc.), makes this problem difficult. A sidestep is to simply have fresh entropy.

[commandersaki]

Yeah that argument seems more a marketing gimmick than makes technical sense. If the OS RNG needs fresh entropy it can reseed with fresh entropy from various sources as it does today and use fast key erasure for forward resistance. Sure there will be windows of opportunity of state compromise, but if the state can be compromised then you have deeper problems, for example they can copy the output of a TRNG source. It's just wasteful to spend a large amount of money on a problem that has a negligible chance of ever actually happening, and in reality would only potentially patch one small issue in what would be a larger shitstorm.

[kurikuri]

> If the OS RNG needs fresh entropy it can reseed with fresh entropy from various sources as it does today and use fast key erasure for forward resistance.

This assumes that the OS has access to a source of entropy that replenishes itself quickly enough for whatever the OS is using. One of the biggest complaints I’ve seen from customers selecting entropy sources is the speed of ‘built-in’ entropy sources, to the point where they will actively look for faster ones and pay quite a bit more when they do genuinely need them. The market is there.

While they could implement the fast key erasure, there is still the looming threat of future mathematic attacks on it, and if some analysis comes forward which shows a way to abuse this, then the house of cards falls down. While these attacks are a concern with any DRBG instantiation, the sidestep is, once again, fresh entropy.

If you happen to need a certification for your entropy source, fast key erasure, as described, doesn’t map cleanly to the SP 800-90 series (NIST’s RNG standards) or the AIS 20/31 (BSI’s RNG standards). Most of the time, people wanting high speed entropy are wanting it in a way that not only they trust it, but in a way where governments would too. While I think there could be a way to define the fast key erasure in terms of SP 800-90C, I don’t think there is an implementation that NIST has approved yet.

> Sure there will be windows of opportunity of state compromise, but if the state can be comprised you have bigger problems, for example they could just copy the output of a TRNG source.

This type of compromise (copying the output of TRNG) is an issue outside the scope of the DRBG’s state… Replicating, calculating, or leaking the DRBG state does not require a persistent listener after the initial compromise, would likely be undetectable to the user, and would be effective until the user gets fresh entropy.

[commandersaki]

I’ve seen from customers selecting entropy sources is the speed of ‘built-in’ entropy sources, to the point where they will actively look for faster ones and pay quite a bit more when they do genuinely need them. The market is there.

Sure and customers buy Monster cables because they've been told they sound better. I'm sure there's a market, but exactly what is this genuine need and do they really understand their own problem? Also for more than a decade now modern systems have a fast entropy source with on chip RNG such as RDRAND and this extends to the embedded context.

[kurikuri]

> I'm sure there's a market, but exactly what is this genuine need and do they really understand their own problem?

Unfortunately, my information stops at the fact that they claim to need the high-output entropy source.

> Also for more than a decade now modern systems have a fast entropy source with on chip RNG such as RDRAND and this extends to the embedded context.

On-chip RNGs are useful, yes, and are often enough for most use cases. In particular, I like Intel’s RDSEED quite a bit, but the larger (in terms of core count) the chips have gotten, the more convoluted the distribution network for the material has become. Even still, the speed of RDSEED (note, RDRAND is an automatically reseeded DRBG, whereas RDSEED is an RBG3 XOR construction (as defined in SP 800-90C) which has fresh entropy in each output) has fallen to a rate in which some vendors are looking for something faster.

[GoblinSlayer]

Fast key erasure uses symmetric cipher. If there's a mathematical attack on that, then you just don't have any symmetric cipher, or you need to rekey faster than fast key erasure, i.e. rekey every 16 bytes of plaintext or even faster. You need a custom protocol for this, how is that certified?

[kurikuri]

> Fast key erasure uses symmetric cipher. If there's a mathematical attack on that, then you just don't have any symmetric cipher

The generation of the RNG’s output stream is the result of a symmetric cipher, yes, but an attack doesn’t need to be on the cipher as a whole. And, once again, if there is a state leakage at any point we end up with the same problem that any future output of the key stream can be undetectably replicated. Sure, you can always replace the key sooner, but that only better protects against the state leakage; the output sequence is still deterministic no matter how fast you replace it.

> You need a custom protocol for this, how is that certified?

This is where cybersecurity testing labs are useful, especially ones who can do entropy source validation. If the protocol itself can be described in terms of the standard, and fulfill its requirements, then it can be easily certified. If there is no way to map the behavior to the standard, but the behavior is secure (according to the lab), the SMEs at the lab can request guidance from the certifying body on how to deal with the situation. These requests have culminated in public guidance (e.g., the FIPS 140-3 IGs) on how to certify industry specific protocols.