10 ms·
It was always the right answer to feed all available entropy sources (irrespective of previous laundering -- eg. Intel RDRAND gets laundered through the SP800-9
by ctz 13y ago
It was always the right answer to feed all available entropy sources (irrespective of previous laundering -- eg. Intel RDRAND gets laundered through the SP800-90 AES-CTR_DRBG internally) into a decent CSPRNG. Feeding multiple entropy sources of different qualities, speeds or backdooredness cannot (by construction) decrease the entropy of the output (it can, obviously, fail to increase it -- say if your ring oscillator got stuck in a fixed bit pattern like the Taiwanese smartcards).
Yarrow and Fortuna are examples of decent CSPRNGs, so I'd say this is a pretty good move by FreeBSD.
- Peaker 13y agoIf the RNG instructions are malicious, they can reduce entropy, by for example XOR'ing into the result previous register values that held the previous entropy source values.
- klodolph 13y agoThat doesn't reduce entropy, it just fails to increase it.
- Peaker 13y agoIt might reduce it, if it XORs away entropy that was previously XOR'd into it.
- ars_technician 13y agoSorry, that's not how entropy works with XOR. If you do not know one of the inputs to an XOR, you know nothing about the output. XORing random sources is great because it acts as a minimum function for entropy of all of the sources. As long as you have just one good source, the output is good.
- wtallis 13y ago> If you do not know one of the inputs to an XOR Aren't we talking about potential backdoors built in to the CPU? As in, having full access to all the registers?
- gefh 13y agoThe processor could recognize that it is in common key generation code, and generate 'entropy' that precisely reverses most of the existing entropy. The existing 'good' entropy could be known by the hardware PRNG.
- ars_technician 13y ago>The processor could recognize that it is in common key generation code This is very unrealistic. It would mean that processors have to be shipped with every crypto library implementation baked into the hardware. Any update would immediately break it.
- tedunangst 13y agoThe processor can also just write whatever it wants into the memory containing the entropy pool even if you never call the RDRAND instruction.
- dpe82 13y agoSure, but that's detectable. gefh's attack is not.
- tedunangst 13y ago
- Perseids 13y agoAren't you talking about the Linux kernel? There the very last step is XOR'ing the random output with the hardware RNG. The article explicitly mentions Yarrow as a mixing and CSRNG function for FreeBSD though.
- michaelt 13y agoAs I understand it when you read from /dev/random it checks a measure of entropy and blocks if there isn't sufficient entropy available. Do we trust hardware RNGs enough to allow their output to increase that measure of entropy?
- X-Istence 13y ago/dev/random is not blocking on FreeBSD.
- tptacek 13y agoEven if it was, like Linux's weird RNG, the security distinction is not particularly meaningful. Developers should generally use urandom.
- ars_technician 13y agoYou are wrong. Developers should use random if it's for something security sensitive like generating keys. random will block when entropy is too low, urandom will just continue recycling entropy, which is cryptographically dangerous.
- Tomte 13y agoI'm sorry, but this meme is flat-out wrong. /dev/urandom gives the exact same quality randomness as /dev/random (let's ignore the issue of boot-time and VM cloning for now). There is a slight twist to it, where for information-theoretically secure algorithms /dev/random would be preferable, but you don't need that. Because you don't use those algorithms (the only one really worth mentioning is Shamir's secret sharing scheme). I'm just amazed how people don't trust the cryptographic building blocks inside a modern CSPRNG, but then use the very same building blocks to use the randomness and encrypt their secrets.
- deathanatos 13y agoA PRNG must be seeded. CSPRNGs are no different, right? In a normal PRNG, if you want X different possible outputs, you must be able to seed it with at least X different seeds. Since each seed corresponds to an output sequence, you need at least as many values for a seed as you wish output sequences. Of course, this seed should be random, and you can't really use a PRNG to seed a PRNG. How do CSPRNGs get around this? I assume that if I have a CSPRNG, I must seed it, and that I must draw that seed from a pool of seeds at least as big as the desired set of output streams. (See above.) If my intent is to generate 4096 random bits (say, for an encryption seed), to me it seems I must input a random seed at least that long. Thus, I need a good RNG. Take a look at Wikipedia's definition[1], for example, of what a CSPRNG must do (as opposed to just any old PRNG): • Every CSPRNG should satisfy the next-bit test. • Every CSPRNG should withstand "state compromise extensions". In the event that part or all of its state has been revealed (or guessed correctly), it should be impossible to reconstruct the stream of random numbers prior to the revelation. Additionally, if there is an entropy input while running, it should be infeasible to use knowledge of the input's state to predict future conditions of the CSPRNG state. Let's assume our CSPRNG of choice satisfies that. The problem is that second one only applies to "preceeding bits". If I know the state of the CSPRNG, I can predict future output. If Linux is low on entropy, or runs out, does this not diminish the number of possible inputs or seeds to the CSPRNG, allowing me to guess, or narrow down my guesses, to the state/seed of the CSPRNG, perhaps prior to it generating output? Am I going wrong somewhere? [1]: http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator http://en.wikipedia.org/wiki/Cryptographically_secure_pseudo...
- spacehome 13y agoUnfortunately, this statement is only true if your entropy sources are uncorrelated. If your new entropy source is correlated in precisely the right way to cancel with a previous entropy source, you reduce entropy of the result.
- Perseids 13y agoWith a cryptographic primitive like Yarrow finding this precisely right way should be infeasible, in the same way that finding a collision for a cryptographic hash function should be infeasible.
- midas007 13y agoFortuna supersedes Yarrow FAIAP. Fortuna has the advantage of making it harder to game entropy pools. [1] [1] http://th.informatik.uni-mannheim.de/people/lucks/papers/Ferguson/Fortuna.pdf http://th.informatik.uni-mannheim.de/people/lucks/papers/Fer...