OpenBSD disk encryption (2015)
xn--thibaud-dya.fr
xn--thibaud-dya.fr
The BSDs have worked on shoestring budgets. Let's hope this attention leads to more sponsorship!
Worth mentioning, BSD were the only systems that disabled Intels RNG after leaks that it might be compromised and Intel cooperate with NSA.
https://www.freebsdfoundation.org/donate/
Perhaps Intel's RNG can, in some cases, be persuaded to produce a low-quality, or otherwise broken stream. This seems plausable (there could be a deniable 'bug' which causes this to happen), but there are many low quality data streams fed into the random number generator, it never hurts to add another.
However, for things like VMs, soon after startup the CPU RNG is about the only possible source of random data, so I suspect there are more users who are being hurt by not having a well enough seeded RNG than those being helped by it being disabled (which is none).
If these two points seem contradictory, they are not. It would always be better to have multiple sources of quality input to the RNG, because as long as one of them isn't corrupted / low quality, you will get decent quality random numbers out. Safety in numbers!
There's a hidden assumption here that they are independent. Without malice, that will be true. However, a malicious CPU might, for example, sniff other sources in order to produce a bad mixture. It's unlikely, but not impossible, and certainly something that intelligence agencies would do if they had the chance.
You could, in principle, hard-wire understanding of some kernel's version of the mixer, and crack the used hashing function, and then inject nasty bits into the random number generator.
However, there is no way you could ever plausibly deny what you did at a future date when the chip is eventually photographed and you could easily break it by just tweaking the random number generator (which happens almost every kernel version anyway, as new methods of gathering randomness are added).
If the CPU really was willing to go to that extent, it would be much, much easier to just monkey-patch the code to edit the register containing the returned random number, whenever rand() (or whatever) is called.
> "XXX - this does not handle the case where the read/write spans across a different key blocks (e.g. 0.5TB boundary). Currently this is already broken by the use of scr_key[0] below."
https://en.wikipedia.org/wiki/Punycode
In Firefox, you can force it to always show the encoded form, as HN had, with network.IDN_show_punycode. Not as pretty, but may protect you against homograph attacks.