3 ms·
Intel's theory I believe was that it could become the only source. The argument in favor I think is the same one you are making now: anything that could hack th
by dooglius 2y ago
Intel's theory I believe was that it could become the only source. The argument in favor I think is the same one you are making now: anything that could hack the chip deeply enough to break rdrand is powerful enough to achieve the same goals in another way.
- rincebrain 2y agoI'm sure Intel loved that idea, given that I don't think RDRAND showed up on AMD chips for 3 years after Intel launched support for it, and that would let them look much better on a number of benchmarks for that duration...
- formerly_proven 2y agoI think you misunderstand where in the pipeline RDRAND would sit. It's not a high-performance RNG, that instruction takes hundreds of cycles and generates a couple bytes of data. It's used to derive keys for the actual CSPRNG providing e.g. /dev/urandom (which is basically a stream cipher). Having or not having RDRAND would have no performance impact on the CSPRNG.
- rincebrain 2y agoSure, but as I recall, in those days, the system would happily block for a bit if you managed to drain the estimated entropy pool low enough by doing something like generating an openssh key on first boot, so having another source that the competition takes 3 years to implement could have provided noticable performance benefits for things people notice, like how slow first boot is, in the days before zx2c4 looked at Linux's /dev/random code and hit it with hammers. (I'm not insisting on that workflow or example being an uptick, just that that's a concrete example of how having an additional source back then could have caused noticable performance differences. I'm aware you're not calling rdrand for your /dev/urandom or random accesses, now or then.)