3

I saw in the market several hardware options for creating strong RNG to produce strong KEYS:

  • HSM
  • TPM internal TRNG
  • Intel RDSEED (TRNG)/RDRAND

My questions are;

  1. What is the strength/entropy difference between them? (using intel RDSEED is much lower cost than buying an HSM)
  2. Why feeding TRNG seed (like RDSEED) into the PRNG mechanism (RDRAND)? doesn't that lower its strength?
  3. Cant I use RDSEED for creating a key (using KDF) without RDRAND?
kelalaka
  • 48,443
  • 11
  • 116
  • 196
Offir
  • 283
  • 1
  • 3
  • 5

1 Answers1

-3

RDRAND/RDSEED is the focus of all three of your questions here. If you're looking for truly random numbers (as indicated by the trng tag), it's probably worth realising that there is substantial anecdotal and circumstantial evidence that RDRAND/RDSEED isn't a TRNG. Have a look at my analysis from another question, specifically item 10. That indicates that it's not just me spouting weirdo conspiracy theories.

Since my analysis discourages the cheap Intel approach, you're left with TPMs and HSMs. Clearly a HSM costs waay more than a TPM. You could argue that a HSM might be more secure/reliable as they tend to be build to international standards like FIPS and commonly accepted in security scenarios.

The entropies should be identical at 8 bits/byte, but I also offer this warning. How do you know? Computational indistinguishability means that you can't differentiate even a simple construct like $E_k(pepper||time)$ from a truly random sequence. And both hardware are designed tamper resistant, which means that you can't personally audit them. So similarly, look at this TPM criticism.

It's a tough choice as a lot of what applies to my RDRAND/RDSEED thesis also applies to TPMs and HSMs.

As for the remaining two parts:-

  1. Yes, feeding a PRNG from a TRNG seed does lower the mathematical strength of the output. A caveat though is that as long as you create your 128/256 bits of initial Kolmogorov randomness, it should be sufficient for most cryptographic purposes. It just means that the output entropy is no longer truly random. Those 128/256 bits remain a constant no matter the output length. Till you re-seed. This is what occurs inside *nix's \dev\urandom, just using other entropy sources.

  2. RDSEED's raison d'être is key creation and seeding. If you believe that the output entropy is real, then all you have to do is acquire it. You get it in batches of 16 - 64 bits via registers. It's a bit dry, but instructions are here. No KDF is required as it should be truly random at 8 bits/byte and therefore perfectly secure. A KDF is indicated when going from a password to a key.

SEJPM
  • 45,967
  • 7
  • 99
  • 205
Paul Uszak
  • 15,390
  • 2
  • 28
  • 77
  • 2
    That proves that it's not just me spouting weirdo conspiracy theories. - The link is to a mostly down voted answer that doesn't appear to prove anything (certainly not in the mathematical sense of the word). Is it really fair and honest to make claims like that? To me it looks awfully misleading. The linked answer also runs contrary to the up voted answer on the very same question (implication being that the linked answer is not exactly the communities consensus) – Ella Rose Dec 13 '19 at 15:08
  • @EllaRose Well, presently that link is +3/-4 which is kinda drawn ;-) And recall Marcus Aurelius - "that all is but opinion and conceit". The important thing is that people think about the 10 pieces of evidence (and supporting links) I’ve provided and form their own opinions. I’m not sure an "I read it on Wiki" answer is comparable or a consensus. Someone quoted Whitfield Diffie, saying "that if you can generate random numbers, you can have a private conversation." Personal privacy is orthogonal to state security, so we need to ask cui bono if I’m right? – Paul Uszak Dec 13 '19 at 16:14
  • The important thing is that people think about the 10 pieces of evidence (and supporting links) I’ve provided and form their own opinions - Great, we can agree on that completely. However, my criticism of the formulation and presentation of that statement still stands - it claims a "proven" result, and the link does not effectively support the claim. This is not a helpful/useful/clear way of communicating information to others. Helpful/useful/clear are the voting criteria, which is why I mention them. – Ella Rose Dec 13 '19 at 16:28
  • intel: "The numbers retuned by RDSEED have multiplicative prediction resistance. If you use two 64-bit samples with multiplicative prediction resistance to build a 128-bit value, you end up with a random number with 128 bits of prediction resistance (2128 * 2128 = 2256). Combine two of those 128-bit values together, and you get a 256-bit number with 256 bits of prediction resistance. You can continue in this fashion to build a random value of arbitrary width and the prediction resistance will always scale with it. ". intel does declares it as good as TPM mech (both are FIPS140/NIST800-90B) – Offir Dec 15 '19 at 05:43
  • 1
    You may also want to note that there are TPMs with FIPS 140 certification, e.g. this one – SEJPM Dec 15 '19 at 13:46
  • The previous edit was meant to modify the answer as to not misrepresent its sources with minimal changes. Please do not misrepresent your sources. The particular source in this context is a collection of indicators supporting a certain claim and not a proof (under which most people in this context would understand an unrefutable argument in favour of a claim). – SEJPM Dec 16 '19 at 16:10
  • @SEJPM OK, I'll leave it then and just disagree. I would certainly welcome any evidence to the contrary though... – Paul Uszak Dec 16 '19 at 17:14