Hacker News Reader

Comment by kurikuri | Hacker News Reader

No, they aren’t gimmicks. The advantage of a quantum-based entropy sources are that they are often much faster than other hardware based entropy source. They are called ‘quantum’ because they exploit randomness present in particle behaviors described by quantum physics (photon behavior on a beam splitter, etc.). Even ring oscillator based random number generators have quantum effects that contribute to its jitter (think shot noise, as an example), but the analysis of its randomness didn’t require quantum physics to describe it.

Quantum RNGs don’t exploit some ‘quantum computing’ property and are strictly limited to a different type of noise from the usual physical noise sources (ring oscillators, phase locked loops, etc.).

View on HN

> The advantage of a quantum-based entropy sources are that they are often much > faster than other hardware based entropy source.

What kind of problem is solved by a fast, hardware-based entropy source? You only need a couple of bytes of entropy to initialize your RNG.

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.

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.

> 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.

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.

> 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.

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?

> 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.

My point is that you don't need an extravagant Quantum source for randomness, and you definitely don't need high throughput. It's really a solution looking for a problem.

Also, I've seen numerous people working in the Quantum space claim that metastability is a quantum effect of ring oscillators, but very doubtful and the literature around it never mentions the q-word.

Most people do not need high throughput entropy sources, sure. But the people who do pay quite a bit for that functionality.

I also haven’t seen any oft-referred literature describing metastability do so using a quantum-physics context. The metastability itself is a product of quantum behavior but has been described well enough without needing it. Depending on what you’re exploiting randomness-wise (like the metastability or the oscillation period length), the type of physical description you use to analyze the noise source changes quite a bit. For most ring oscillator work, I prefer to look at the work near the 2000’s by Ali Hajimiri, none of which is in terms of quantum anything.

Reply on news.ycombinator.com