8 ms·

> we need to get over people's distrust of Intel and RDRAND. Am I misreading this or is Ted T'so really suggesting that we should all just stop worrying and lo

> we need to get over people's distrust of Intel and RDRAND. Am I misreading this or is Ted T'so really suggesting that we should all just stop worrying and love the secret and compeltely unauditable RNG offered by the same company that has literally backdoored every CPU they've sold in the past 12 years?

masklinn 7y ago
You're cutting off the first half of the quote which is pretty damn relevant: > we need to find some way to fix userspace's assumptions that they can always get high quality entropy in early boot, or we need to get over people's distrust of Intel and RDRAND Though ts'o is also ignoring the third option — and the one used by openbsd — of storing an rng seed after boot (and on shutdown). The very first boot does remain problematic if the image isn't seeded though.
- boring_twenties 7y ago
  How is it relevant? The fact that he's proposing an alternative option doesn't change the fact that he's also presenting a completely insane one.
  - zamadatix 7y ago
    In the same way "We need to stop driving the boat into rocks or..." is relevant context to "...we need to start liking to swim". Just because something is listed as an option does not mean the speaker is interested in actually doing that. It's a speaking pattern meant to convey "we've got to do something about <x> and people don't like <y> (so it's gotta be <x>)". In reality there are almost always more <options> than the duality implies but at no point does the person ever actually want <y>.
    - boring_twenties 7y ago
      I can't quite put my finger on it, but there is something in Tso's statement that seems to me to be quite different from yours. In your example, the fact that the first option is self-evidently correct even in a vacuum, is something of a cue that the second option isn't meant to be taken as seriously. In Tso's statement, it's not immediately clear to me which of the two options he prefers. In fact, his use of the phrase "get over it" leads me to think that is actually his preferred variant. To me, that phrasing means if not an outright trivial and unworthy concern, then at least one that only needs the passage of time. There doesn't seem to be any indication that he's using the phrase ironically or anything. Of course it is always possible that I'm just misreading or misinterpreting it. But that is why the first half didn't, and still doesn't, seem relevant to me.
- cpeterso 7y ago
  Ubuntu's man pages say "all major Linux distributions have [saved a seed file across reboots] since 2000 at least": http://manpages.ubuntu.com/manpages/trusty/man4/random.4.html http://manpages.ubuntu.com/manpages/trusty/man4/random.4.htm...
  - wahern 7y ago
    Lennart, posting as mezcalero, addresses that in the LWN discussion. TL;DR: systemd loads the seed too late in the boot process, which is a deliberate choice on their part.
- jnurmine 7y ago
  But is it really that difficult to seed the image for that first boot? For example, an installation process using an .iso image could, after verifying the .iso, put a random seed inside the .iso (unpack-modify-pack) as a pre-configuration step. Like an extra preparation step after downloading. New installation = new pre-configuration step, to avoid seed reuse. The previous would apply to VMs and containers and such. For traditional embedded/IoT style devices, the step could be done at the factory when flashing the image. Or maybe there could be a small flash area with the seed as part of the initial flashing procedure. I guess some forms of installation end up being "problematic" to handle (ro root filesystems maybe).
  - saagarjha 7y ago
    > unpack-modify-pack This seems eminently unfeasible for many applications, and it won't work at all for read-only filesystems as you've mentioned.
  - wahern 7y ago
    A VirtIO-RNG driver has been in Linux for over 10 years: https://wiki.qemu.org/Features/VirtIORNG https://wiki.qemu.org/Features/VirtIORNG Randomness in VMs isn't a problem. If VM hypervisors aren't providing VirtIO-RNG, it's still just a quick fix and reboot away. The quickest way to make sure all hypervisors and hosting providers enable VirtIO-RNG, or something similar, is for the kernel to being assuming, loudly, that strong entropy is available at boot time. For embedded stuff SPI RNG chips and similar solutions have been available since forever, not to mention the on-chip sources on most modern ARM and x86 CPUs and SoCs. If a product designer (e.g. embedded device) or solution provider (cloud hosting) chooses to put their trust in RDRAND alone, then that's their choice--Linux shouldn't be second guessing it, or at least allow such a choice to dictate the semantics of its APIs.
    - denton-scratch 7y ago
      VirtIO-RNG has not been officially accepted into Xen (it seems to be easier to incorporate into a PV DOMU). If you have RDRAND hardware, you could (I suppose) pipe it's output from DOM0 into an encrypted root terminal session on DOMU, and feed that into the pool. I personally don't want to rely on RDRAND. Unlike a tampered ADD instruction, a tampered RDRAND instruction would appear to be undetectable, even in principle. I wish Intel had given me the raw bits from their DRBG, instead of providing only the whitened stream. Or hell, give me both - but not just an opaque stream.
temac 7y ago
If you make the hypothesis your CPU is completely compromised, it is vain to be hysterical about rdrand. Any sane random gen does not pass it directly to consumers, anyway (it always goes through at least an irreversible hash function with other inputs)
- HugoHobling 7y ago
  It isn't completely vain - consider djb's blog post that discusses this exact scenario: https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html
  - temac 7y ago
    That was exactly what I was thinking about. This is a quite impractical attack, in the sense that if you are able to do that, you are able to do way more simple attacks, like tuning the final output without even going through the pretend & mine phase -- that could be more effective btw, depending on the mixing algo and the presence of true randomness in the mix or not, but arguably slightly easier to detect. So the hw rng path would only be reserved to extremely high profile targets subject to APT, and those target better generate their keys on dedicated hardware, or there will be 10000 manner for them to be owned. (and even if they do on dedicated hardware, subject to an attacker so motivated, I predict they are still owned...) And above all: you will also probably be able to modify others supposed sources of entropy (if you restrict yourself to sources, I still think it is a terrible idea if you have that kind of capabilities), so short of analyses showing why this would be way more difficult, dropping the dedicated hw gen for a theoretical problem that would also be an end-game for virtually everything else is insane. You get no actual advantages, and tons of drawbacks. Really, the hypothesis of what the attackers are able to do and what they are not makes no sense IMO; like: > For example, an attacker can't exert any serious control over the content of my keystrokes while I'm logged in; I don't see how hashing this particular content into my laptop's entropy pool can allow any attacks. Yeah, so that mythical unicorn can invoke utter craziness in RDRAND, but is somehow unable to modify the key inputs and/or timings just when that data reaches the entropy input algos? I just don't buy it. Like I don't buy that the user is somehow recomputing everything on a second computer and comparing both results (or using other fancy proof of work things, that I'm not aware that even exist on real code we are talking about). My litmus test is: imagining I'd have to attack, I would never do it by such a convoluted method. Or maybe only ever if Ben Laden Two is the target, AND if it seems to actually make sense in the technical context of the attack: the proba of both occurring is, I guess, quite low...
danieldk 7y ago
Am I misreading this or is Ted T'so really suggesting that we should all just stop worrying and love the secret and compeltely unauditable RNG offered by the same company that has literally backdoored every CPU they've sold in the past 12 years? Doesn't it all depend on how you are using it? As far as I recall, Linux does not use RDRAND is a direct source for random numbers, but rather mixes it with the entropy pool. Since xor'ing with (potentially) low-entropy data does not reduce the entropy, the argumentation is that it is safe. The potentially backdoored RDRAND is problematic as a source of random numbers or when the entropy has too little entropy (since RDRAND would determine the entropy).
- boring_twenties 7y ago
  Well yes. Except if, as others have noted, the hypothetical malicious RDRAND can read the state of the entropy pool as well. Of course that's a totally different and more complex attack. Is it still plausible enough to possibly worry about? I have no idea, honestly -- this is way outside my area of expertise. What I do know is that hardware RNGs made from open-source and verifiable hardware is readily available for about US$50 for qty 1, cheaper in bulk. Given that, it doesn't seem worth more than a couple of minutes investigating whether or not RDRAND can be trusted. If there is the slightest hint of doubt, I just disable it and move on with life.
- dependenttypes 7y ago
  > Linux does not use RDRAND is a direct source for random numbers, but rather mixes it with the entropy pool. Since xor'ing with (potentially) low-entropy data does not reduce the entropy And this is still insecure https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html
  - cryptonector 7y ago
    DJB is not saying that an entropy pool is insecure, as you put it. Nor is he saying that one shouldn't bother with a PRNG seeded with RDRAND and/or other hardware sources of entropy. DJB has an axe to grind (and rightly so) here in that he's pushing cryptographic algorithms that need less (or no) entropy. Specifically EdDSA instead of ECDSA. And he's also dismantling some of the bad arguments about how /dev/urandom should operate. An operating system doesn't know why an application needs entropy, just that it does, and I don't see the problem with having an SRNG for that purpose. DJB doesn't even say that a system SRNG is not good, but, rather, he's quite sensibly saying that _applications_ should stretch one good 256-bit chunk of entropy. And yes, DJB correctly points out that there's no need to have security relative to an attacker that once saw the entire state of the SRNG at an earlier point in time -- but that does not mean that a kernel-land SRNG shouldn't add entropy to its pool, just that it doesn't buy you much.
wahern 7y ago
On most modern systems, especially laptops and servers, RDRAND is only one of multiple hardware RNGs available. And except on first boot there's also the seed--partly derived from interrupts, etc--from previous boots that can be mixed back in. I think the sentiment (or at least my sentiment) is that the number of systems where early entropy is used for something important like key generation but that lack strong sources is diminishing. Many, if no most, x86 and ARM embedded platforms over the past ~5 years have had at at least an on-chip RNG, and over the past 5-10 years some at least some on-board RNG (e.g. Intel NIC controllers often contain an RNG, AMDs PSP provides an RNG, plus various other options like SPI RNG chips). Ideally there would be multiple sources, but ultimately it's the designer's choice. Likewise, any new platform that lacks any source but has software that expects strong entropy is unequivocally broken. Older systems are disappearing and are unlikely to be upgraded, anyhow. Excessive paranoia about RDRAND is counter productive. It's speculation that it's weak, while we know for a fact that the machinations userland code goes through to work around the poor semantics and unreliability of Linux kernel randomness interfaces has caused and is causing real problems, including real security problems. At some point the risk of a bugged RDRAND is less than the risk of assuming a non-bugged RDRAND. Plus, if the kernel is loud about its expectations for quality hardware sources it creates an environment where people (embedded designers, savvy laptop purchasers) demand quality sources and manufacturers will compete along that axis (more so than they already do--the VIA C3 was the first to add an on-chip RNG on a mass production chip nearly 15 years ago).
- hinkley 7y ago
  I got wedged about six months ago trying to fast iterate on creating a Docker image on Docker for OS X. I exhausted the entropy on the Linux VM and IIRC, one of the package managers started hanging trying to fetch packages over SSL. Ten years back I had an embedded app that was struggling with this. It's always been my assumption/fear that jitter on an RTOS is not a particularly rich source of entropy. Not to the degree of a Linux kernel sitting on a loud network (maybe switches have worsened this as well?) Thankfully the system had a few things going for it. First, the flavor of PRNG we were using had a seed function that was cumulative (not all are). Second, useful implementation of system time in nanoseconds (at the time, not a given). And third, the writers had a longish list of bootstrapping tasks to perform prior to making any network calls. The code that started these tasks was all located in one bootstrapping file. So in addition to whatever crap entropy the libraries could gin up, we pushed another handful of bits of entropy in for each task by taking the nanoseconds and stuffing it into the seed data. doTask1(), seed(nanos()), doTask2(), etc. This is the same observation made in Linux's RNG, and that is demonstrated in the algorithm for randomness from a biased coin: A high quality mixing algorithm and a large volume biased data can be transformed into a smaller quantity of high quality entropy. Which makes me wonder why Linux doesn't use RDRAND with a low entropy estimate to augment the early sources.
tytso 7y ago
If you don't trust Intel, then don't use Intel CPU's at all. Using Intel CPU's and simultaneously saying, "but we can't trust RDRAND because could be backdoored" is completely insane. Intel hid an entire x86 core running minix --- with security holes --- and told no one. Between the firmware code which runs in System Management Mode and in UEFI, which persists after the OS is booted and can take over the system and read and write arbitrary memory locations --- if you fear a backdoor in the CPU, RDRAND is not the only place where an attacker can screw you over. The bottom line is the entire CPU can not be audited. So trust it. Or don't trust it. Use another CPU architecture. Or go back to using pen and paper, and don't use any computers or cell phones at all. We have to trust the bootloader to verify the digital signature on the kernel, so we might as well trust the bootloader to get a secure random seed. But from where? It could call UEFI or try use the RNG from the TPM (if available). But now you have to trust Intel, and/or the motherboard manufacturer, and/or the TPM. The bootloader could read from a seed file from the HDD/SSD. But we know that nation-state intelligence agencies (like the NSA) have the capability of implanting malware into HDD firmware (which is also unauditable), and we also know that we can't trust most consumer grade manufacturers or IOT devices to correctly insert device-specific secure entropy into the seed file at manufacturing time. Otherwise, all of the seed files will likely have the same value, at which point when the device is generating its long-term private key, immediately after it is first plugged in, the key will very likely be weak (see the "Mining your p's and q's"[1] paper). The bottom line is that unless you propose to personally wire up your CPU from transistors, and then create your own compiler from assembly language (see the "Reflections on Trusting Trust"[2] paper by Ken Thompson about what can be hidden inside an untrustworthy compiler), and then personally audit all of the open source code you propose to compile using that compiler and use on your system, you have to trust someone. What makes this political, and difficult to address, is everyone has different opinions on what they are willing to trust and not trust. But some combinations, such as "we can't trust Intel because their firmware can't be audited", and "but we insist on using Intel CPU's", really don't make much sense. [1] https://factorable.net https://factorable.net [2] https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...
- cesarb 7y ago

masklinn 7y ago

You're cutting off the first half of the quote which is pretty damn relevant: > we need to find some way to fix userspace's assumptions that they can always get high quality entropy in early boot, or we need to get over people's distrust of Intel and RDRAND Though ts'o is also ignoring the third option — and the one used by openbsd — of storing an rng seed after boot (and on shutdown). The very first boot does remain problematic if the image isn't seeded though.

boring_twenties 7y ago
How is it relevant? The fact that he's proposing an alternative option doesn't change the fact that he's also presenting a completely insane one.
- zamadatix 7y ago
  In the same way "We need to stop driving the boat into rocks or..." is relevant context to "...we need to start liking to swim". Just because something is listed as an option does not mean the speaker is interested in actually doing that. It's a speaking pattern meant to convey "we've got to do something about <x> and people don't like <y> (so it's gotta be <x>)". In reality there are almost always more <options> than the duality implies but at no point does the person ever actually want <y>.
  - boring_twenties 7y ago
    I can't quite put my finger on it, but there is something in Tso's statement that seems to me to be quite different from yours. In your example, the fact that the first option is self-evidently correct even in a vacuum, is something of a cue that the second option isn't meant to be taken as seriously. In Tso's statement, it's not immediately clear to me which of the two options he prefers. In fact, his use of the phrase "get over it" leads me to think that is actually his preferred variant. To me, that phrasing means if not an outright trivial and unworthy concern, then at least one that only needs the passage of time. There doesn't seem to be any indication that he's using the phrase ironically or anything. Of course it is always possible that I'm just misreading or misinterpreting it. But that is why the first half didn't, and still doesn't, seem relevant to me.
cpeterso 7y ago
Ubuntu's man pages say "all major Linux distributions have [saved a seed file across reboots] since 2000 at least": http://manpages.ubuntu.com/manpages/trusty/man4/random.4.html http://manpages.ubuntu.com/manpages/trusty/man4/random.4.htm...
- wahern 7y ago
  Lennart, posting as mezcalero, addresses that in the LWN discussion. TL;DR: systemd loads the seed too late in the boot process, which is a deliberate choice on their part.
jnurmine 7y ago
But is it really that difficult to seed the image for that first boot? For example, an installation process using an .iso image could, after verifying the .iso, put a random seed inside the .iso (unpack-modify-pack) as a pre-configuration step. Like an extra preparation step after downloading. New installation = new pre-configuration step, to avoid seed reuse. The previous would apply to VMs and containers and such. For traditional embedded/IoT style devices, the step could be done at the factory when flashing the image. Or maybe there could be a small flash area with the seed as part of the initial flashing procedure. I guess some forms of installation end up being "problematic" to handle (ro root filesystems maybe).
- saagarjha 7y ago
  > unpack-modify-pack This seems eminently unfeasible for many applications, and it won't work at all for read-only filesystems as you've mentioned.
- wahern 7y ago
  A VirtIO-RNG driver has been in Linux for over 10 years: https://wiki.qemu.org/Features/VirtIORNG https://wiki.qemu.org/Features/VirtIORNG Randomness in VMs isn't a problem. If VM hypervisors aren't providing VirtIO-RNG, it's still just a quick fix and reboot away. The quickest way to make sure all hypervisors and hosting providers enable VirtIO-RNG, or something similar, is for the kernel to being assuming, loudly, that strong entropy is available at boot time. For embedded stuff SPI RNG chips and similar solutions have been available since forever, not to mention the on-chip sources on most modern ARM and x86 CPUs and SoCs. If a product designer (e.g. embedded device) or solution provider (cloud hosting) chooses to put their trust in RDRAND alone, then that's their choice--Linux shouldn't be second guessing it, or at least allow such a choice to dictate the semantics of its APIs.
  - denton-scratch 7y ago
    VirtIO-RNG has not been officially accepted into Xen (it seems to be easier to incorporate into a PV DOMU). If you have RDRAND hardware, you could (I suppose) pipe it's output from DOM0 into an encrypted root terminal session on DOMU, and feed that into the pool. I personally don't want to rely on RDRAND. Unlike a tampered ADD instruction, a tampered RDRAND instruction would appear to be undetectable, even in principle. I wish Intel had given me the raw bits from their DRBG, instead of providing only the whitened stream. Or hell, give me both - but not just an opaque stream.

temac 7y ago

If you make the hypothesis your CPU is completely compromised, it is vain to be hysterical about rdrand. Any sane random gen does not pass it directly to consumers, anyway (it always goes through at least an irreversible hash function with other inputs)

HugoHobling 7y ago
It isn't completely vain - consider djb's blog post that discusses this exact scenario: https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html
- temac 7y ago
  That was exactly what I was thinking about. This is a quite impractical attack, in the sense that if you are able to do that, you are able to do way more simple attacks, like tuning the final output without even going through the pretend & mine phase -- that could be more effective btw, depending on the mixing algo and the presence of true randomness in the mix or not, but arguably slightly easier to detect. So the hw rng path would only be reserved to extremely high profile targets subject to APT, and those target better generate their keys on dedicated hardware, or there will be 10000 manner for them to be owned. (and even if they do on dedicated hardware, subject to an attacker so motivated, I predict they are still owned...) And above all: you will also probably be able to modify others supposed sources of entropy (if you restrict yourself to sources, I still think it is a terrible idea if you have that kind of capabilities), so short of analyses showing why this would be way more difficult, dropping the dedicated hw gen for a theoretical problem that would also be an end-game for virtually everything else is insane. You get no actual advantages, and tons of drawbacks. Really, the hypothesis of what the attackers are able to do and what they are not makes no sense IMO; like: > For example, an attacker can't exert any serious control over the content of my keystrokes while I'm logged in; I don't see how hashing this particular content into my laptop's entropy pool can allow any attacks. Yeah, so that mythical unicorn can invoke utter craziness in RDRAND, but is somehow unable to modify the key inputs and/or timings just when that data reaches the entropy input algos? I just don't buy it. Like I don't buy that the user is somehow recomputing everything on a second computer and comparing both results (or using other fancy proof of work things, that I'm not aware that even exist on real code we are talking about). My litmus test is: imagining I'd have to attack, I would never do it by such a convoluted method. Or maybe only ever if Ben Laden Two is the target, AND if it seems to actually make sense in the technical context of the attack: the proba of both occurring is, I guess, quite low...

danieldk 7y ago

Am I misreading this or is Ted T'so really suggesting that we should all just stop worrying and love the secret and compeltely unauditable RNG offered by the same company that has literally backdoored every CPU they've sold in the past 12 years? Doesn't it all depend on how you are using it? As far as I recall, Linux does not use RDRAND is a direct source for random numbers, but rather mixes it with the entropy pool. Since xor'ing with (potentially) low-entropy data does not reduce the entropy, the argumentation is that it is safe. The potentially backdoored RDRAND is problematic as a source of random numbers or when the entropy has too little entropy (since RDRAND would determine the entropy).

boring_twenties 7y ago
Well yes. Except if, as others have noted, the hypothetical malicious RDRAND can read the state of the entropy pool as well. Of course that's a totally different and more complex attack. Is it still plausible enough to possibly worry about? I have no idea, honestly -- this is way outside my area of expertise. What I do know is that hardware RNGs made from open-source and verifiable hardware is readily available for about US$50 for qty 1, cheaper in bulk. Given that, it doesn't seem worth more than a couple of minutes investigating whether or not RDRAND can be trusted. If there is the slightest hint of doubt, I just disable it and move on with life.
dependenttypes 7y ago
> Linux does not use RDRAND is a direct source for random numbers, but rather mixes it with the entropy pool. Since xor'ing with (potentially) low-entropy data does not reduce the entropy And this is still insecure https://blog.cr.yp.to/20140205-entropy.html https://blog.cr.yp.to/20140205-entropy.html
- cryptonector 7y ago
  DJB is not saying that an entropy pool is insecure, as you put it. Nor is he saying that one shouldn't bother with a PRNG seeded with RDRAND and/or other hardware sources of entropy. DJB has an axe to grind (and rightly so) here in that he's pushing cryptographic algorithms that need less (or no) entropy. Specifically EdDSA instead of ECDSA. And he's also dismantling some of the bad arguments about how /dev/urandom should operate. An operating system doesn't know why an application needs entropy, just that it does, and I don't see the problem with having an SRNG for that purpose. DJB doesn't even say that a system SRNG is not good, but, rather, he's quite sensibly saying that _applications_ should stretch one good 256-bit chunk of entropy. And yes, DJB correctly points out that there's no need to have security relative to an attacker that once saw the entire state of the SRNG at an earlier point in time -- but that does not mean that a kernel-land SRNG shouldn't add entropy to its pool, just that it doesn't buy you much.

wahern 7y ago

On most modern systems, especially laptops and servers, RDRAND is only one of multiple hardware RNGs available. And except on first boot there's also the seed--partly derived from interrupts, etc--from previous boots that can be mixed back in. I think the sentiment (or at least my sentiment) is that the number of systems where early entropy is used for something important like key generation but that lack strong sources is diminishing. Many, if no most, x86 and ARM embedded platforms over the past ~5 years have had at at least an on-chip RNG, and over the past 5-10 years some at least some on-board RNG (e.g. Intel NIC controllers often contain an RNG, AMDs PSP provides an RNG, plus various other options like SPI RNG chips). Ideally there would be multiple sources, but ultimately it's the designer's choice. Likewise, any new platform that lacks any source but has software that expects strong entropy is unequivocally broken. Older systems are disappearing and are unlikely to be upgraded, anyhow. Excessive paranoia about RDRAND is counter productive. It's speculation that it's weak, while we know for a fact that the machinations userland code goes through to work around the poor semantics and unreliability of Linux kernel randomness interfaces has caused and is causing real problems, including real security problems. At some point the risk of a bugged RDRAND is less than the risk of assuming a non-bugged RDRAND. Plus, if the kernel is loud about its expectations for quality hardware sources it creates an environment where people (embedded designers, savvy laptop purchasers) demand quality sources and manufacturers will compete along that axis (more so than they already do--the VIA C3 was the first to add an on-chip RNG on a mass production chip nearly 15 years ago).

hinkley 7y ago
I got wedged about six months ago trying to fast iterate on creating a Docker image on Docker for OS X. I exhausted the entropy on the Linux VM and IIRC, one of the package managers started hanging trying to fetch packages over SSL. Ten years back I had an embedded app that was struggling with this. It's always been my assumption/fear that jitter on an RTOS is not a particularly rich source of entropy. Not to the degree of a Linux kernel sitting on a loud network (maybe switches have worsened this as well?) Thankfully the system had a few things going for it. First, the flavor of PRNG we were using had a seed function that was cumulative (not all are). Second, useful implementation of system time in nanoseconds (at the time, not a given). And third, the writers had a longish list of bootstrapping tasks to perform prior to making any network calls. The code that started these tasks was all located in one bootstrapping file. So in addition to whatever crap entropy the libraries could gin up, we pushed another handful of bits of entropy in for each task by taking the nanoseconds and stuffing it into the seed data. doTask1(), seed(nanos()), doTask2(), etc. This is the same observation made in Linux's RNG, and that is demonstrated in the algorithm for randomness from a biased coin: A high quality mixing algorithm and a large volume biased data can be transformed into a smaller quantity of high quality entropy. Which makes me wonder why Linux doesn't use RDRAND with a low entropy estimate to augment the early sources.

tytso 7y ago

If you don't trust Intel, then don't use Intel CPU's at all. Using Intel CPU's and simultaneously saying, "but we can't trust RDRAND because could be backdoored" is completely insane. Intel hid an entire x86 core running minix --- with security holes --- and told no one. Between the firmware code which runs in System Management Mode and in UEFI, which persists after the OS is booted and can take over the system and read and write arbitrary memory locations --- if you fear a backdoor in the CPU, RDRAND is not the only place where an attacker can screw you over. The bottom line is the entire CPU can not be audited. So trust it. Or don't trust it. Use another CPU architecture. Or go back to using pen and paper, and don't use any computers or cell phones at all. We have to trust the bootloader to verify the digital signature on the kernel, so we might as well trust the bootloader to get a secure random seed. But from where? It could call UEFI or try use the RNG from the TPM (if available). But now you have to trust Intel, and/or the motherboard manufacturer, and/or the TPM. The bootloader could read from a seed file from the HDD/SSD. But we know that nation-state intelligence agencies (like the NSA) have the capability of implanting malware into HDD firmware (which is also unauditable), and we also know that we can't trust most consumer grade manufacturers or IOT devices to correctly insert device-specific secure entropy into the seed file at manufacturing time. Otherwise, all of the seed files will likely have the same value, at which point when the device is generating its long-term private key, immediately after it is first plugged in, the key will very likely be weak (see the "Mining your p's and q's"[1] paper). The bottom line is that unless you propose to personally wire up your CPU from transistors, and then create your own compiler from assembly language (see the "Reflections on Trusting Trust"[2] paper by Ken Thompson about what can be hidden inside an untrustworthy compiler), and then personally audit all of the open source code you propose to compile using that compiler and use on your system, you have to trust someone. What makes this political, and difficult to address, is everyone has different opinions on what they are willing to trust and not trust. But some combinations, such as "we can't trust Intel because their firmware can't be audited", and "but we insist on using Intel CPU's", really don't make much sense. [1] https://factorable.net https://factorable.net [2] https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.archive.ece.cmu.edu/~ganger/712.fall02/papers/p7...

cesarb 7y ago