Hot answers tagged

34

I think you're misinterpreting the source. The source says the TRNGs "rely" on compression (a cryptographic hash would be the compression function, or possibly some simpler function to increase throughput). The random data isn't insecure after compression, it's insecure before compression. Why? When you roll dice there's an equal probability of it ...


11

Using /dev/urandom to generate cryptographic keys or secrets can be an issue when the state of the OS is not unique. This is the typically case when a VM was just booted from a template: the state of the CSPRNG could be shared among multiple VMs. In cases similar to this one, it is important to use /dev/random or getrandom() instead of /dev/urandom, so that ...


8

One of the failing test discussed in the question was coded for the purpose. It could be useful to validate that code using a known-good pseudo-random source (the output of SHA-256 for incremental values qualifies). If it failed too often, the code would need a fix! The test's definition is complex, for example in 2.7.4 (2) defining how to count the number ...


7

The Electrical Engineering SE would be a good resource for questions about specific sources of noise. Which method is best is not a a question for which you will find a good answer to. The "quality" of any method depends on which models of electronic components are used. They have different properties that don't make direct comparison easy: Power use: Two ...


7

Both ent tests distinguish the files from random data with high confidence (99.84% for the bit test, >99.99% for the byte test). That follows from the "randomly would exceed this value.." reports. It would only be an issue in actual use if the random data was directly used. Which would be bad practice in cryptography, where the rule is that the output of an ...


7

That sounds more difficult than it is in fact. You could build one using light, heath, or a semiconductor that will produce certified noise but it will never be NIST certified. (But that is obviously not what you want) If it is truly random, or not, can be measured and certified. Having a "true random number generator" from just hardware is ...


6

It depends on the goal of performing the test: If the goal is to test for a problem in the whitening, then the test should be run on the whitened output, of course. If the test fails (more often than predicted by the P-value), the whitening is demonstrated bad. If the test pass, we can deduce nothing cryptographically useful (the source or the whitening ...


5

If you fish around in your pocket, you can probably find one that costs 0.25 USD. All it takes to use one of these gizmos is a little patience, a bit of hand-eye coordination, and some confidence that there aren't any surveillance cameras watching you, which you need anyway because you just typed in your password under them to decrypt your laptop's disk. ...


5

I assume your TRNG has a uniform distribution and can generate all possible 32bit numbers (ie. isn't limited to a specific smaller number range, just to [0,2^32-1]). In this case, it doesn't really matter, because the TRNG output is also a stream of truly random single bits, as well as a stream of truly random 2bit pairs (numbers 0-3), etc. If this were not ...


5

There seems to be a lot of confusing terminology here. Let me define everything to the best of my knowledge. RNG: Some mechanism that produces random numbers. CSRNG: An RNG that is safe for cryptographic use. PRNG: An RNG that is a deterministic algorithm based off of a seed. TRNG: An RNG that is based off of some unpredictable physical process. CSPRNG: A ...


4

Yes, RDSEED is a true random number generator. From Wikipedia: The entropy source for the RDSEED instruction runs asynchronously on a self-timed circuit and uses thermal noise within the silicon to output a random stream of bits at the rate of 3 GHz [...]. RDSEED is however used as a seed for (software implemented) PRNGs of arbitrary width.


4

There is no such thing as a random number and as such it is a category error to attempt to verify whether a particular set of numbers is ‘random’. There are random generators of numbers; the relevant question is whether you—or, more importantly, a well-funded adversary—can predict the output when you don't know it a priori. To answer that, you must: Study ...


4

The only reason to use /dev/random is to wait until the system has loaded entropy. If you have waited once, it is generally safe to use /dev/urandom. It has nothing whatsoever to do with speed of output. There is no reason to ever read more than a single byte from /dev/random in an application. Writing a benchmark that measures time to read long outputs ...


4

I'd say the comparison table is not a fair one, as it compares the Infinite Noise generator's throughput when feeding bits into a CSPRNG (Keccak) running on the host workstation and then running that CSPRNG as fast as the workstation allows. Other devices in the table achieve ~10 Mbit/sec speeds, but all of those devices in the table which had enough design ...


3

Ideally a whitening algorithm passes data through cryptographic algorithms, rather than doing something simple (like Von-Neumann's unfair coin de-biasing algorithm or reading the least significant bit of noisy analog-to-digit converters.) If this is the case (and it should be), then testing post-whitened data is useless. If I were responsible for designing ...


3

The one metric that generically matters in cryptography for a physical entropy source is the min-entropy: the exponent of the most probable outcome, in bits. This depends on the physics of the entropy source. As long as it exceeds 256, you can feed a sample through a typical preimage-resistant hash function such as SHAKE256, a conditioner, and you will ...


3

How many patterns are you testing? If you are looking for many different patterns. It is expected that at least one of them would be more common. Normally we want the p value to be small to show an affect and use multi hypothesis correction of some sort. However here that would be cheating in our favour and therefor this is not a good solution. But ...


3

The contract of a true random number generator is that: Every bit it outputs has an equal chance of being a zero as a one; Knowledge of the values of any of the bits it has output in the past is of no help for guessing the value of any bit it will output in the future. These two properties are enough to settle your question; they imply that generating four ...


3

Be careful about the phrase “True Random Number Generator”. There's a bit of hype in that phrase. You do not need to use a TRNG directly to do things like generate cryptographic keys — in fact, you should not, because all TRNG have biases, because even if the underlying physical process has a truly uniform probability distribution, it's impossible to build a ...


3

HSMs are not purchased just for the feature of generating certs. HSMs also store the certificates very securely. You cannot use the cert in the HSM unless you are authorised HSMs also provide very secure management of the HSM itself - for e.g. you can create smart cards for 5 admins & say that atleast any 3 of the cards have to be used to administer ...


3

(Disclaimer: I wrote the passage quoted in the question.) Can an RNG which relies — among other things — on a non-deterministic physical noise source still be called "pseudo" random? I would suggest that yes, this is reasonable, because a computationally unbounded adversary could distinguish its output from a true, full-entropy random stream, but ...


3

You are confusing discrete Gaussian sampling with Gaussian sampling. A discrete Gaussian of parameters $\mu, \sigma$ is a random variable supported on $\mathbb{Z}$ with pmf: $$\Pr[X = k]\propto \exp(-\pi \|x-\mu\|^2/\sigma^2)$$ A continuous Gaussian of parameters $\mu, \sigma$ is a random variable supported on $\mathbb{R}$ with pdf: $$\Pr[X = r] \propto\exp(-...


2

I break it up like this: CS understood for now to be cryptographically secure PR or R an approximation of random or truly random (R,HR,TR all mean the same thing) NG a number generator The number generator is rewarded the CS until it is shown that the numbers are not good enough for any cryptography you thought you could use them for, then you drop the ...


2

What I read from your comments, a HSM is not really what you need. The main purpose of an HSM is to securely store keys, including layers of physical protection. That is what makes them special (and expensive). The second most important feature of an HSM is a special processor which can execute cryptographic operations very fast (think, thousands of RSA ...


2

@SqueamishOssifrage has given an accepted answer, so I assume that it addresses your concerns. However the question as stated was about randomness tests, and I think there's something to add concerning that aspect of the question. I am more familiar with the TestU01 than NIST tests, but based on what I've read in Johnston's Random Number Generators--...


2

As explained in comment and the other answer, "If any deterministic algorithm is used" as in the question's condition 5, then the cryptosystem is not a One Time Pad, it is a cipher; a stream cipher if the encryption is by XOR with a keystream independent of the plaintext. And when we use a cipher, we loose the unconditional security of the OTP. ...


2

tl;dr– It's not actually a true-random generator so much as a physically-sourced-random generator. The underlying physical processes can have patterns that compression helps to strip away, improving the quality of the generator. In context, "true" randomness is referring to randomness sourced from physical phenomena in contrast to pseudo-...


Only top voted, non community-wiki answers of a minimum length are eligible