OpenBSD disk encryption (2015) • Hacker News Board

Re: OpenBSD disk encryption (2015)

#11

Post by beagle3 » Tue, Sep 06, 2016, 5:32 PM UTC

CJefferson wrote: post #8

akerro wrote: post #4

Earlier quoted context omitted.

And DragonFlyBSD provides HAMMER https://www.dragonflybsd.org/hammer/ 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/ https://www.openbsd.org/donations.html https://www.dragonflybsd.org/donations/

With regards the RNG, to be it showed a lack of understanding of how seeding RNG generators work. 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 thing…

> because as long as one of them isn't corrupted / low quality

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.

Re: OpenBSD disk encryption (2015)

#12

Post by CJefferson » Tue, Sep 06, 2016, 6:26 PM UTC

beagle3 wrote: post #11

CJefferson wrote: post #8

Earlier quoted context omitted.

With regards the RNG, to be it showed a lack of understanding of how seeding RNG generators work. 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 thing…

> because as long as one of them isn't corrupted / low quality 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.

That would also require breaking the mixing function (which no-one knows how to do, and is typically a high-quality hashing function), and measuring the other sources (many of which are related to details of how the kernel does various things, like measure hard drive latency).

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.

Re: OpenBSD disk encryption (2015)

#13

Post by RJIb8RBYxzAMX9u » Tue, Sep 06, 2016, 7:06 PM UTC

ktta wrote: post #10

interesting domain name. HN shows it as xn--thibaud-dya.fr but browers show it as thiebaud.fr (accented e) . Reminds me of something I read here on HN about a month ago about the history of web/URLs

It's Punycode.

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.

https://en.wikipedia.org/wiki/IDN_homograph_attack