
OpenBSD disk encryption (2015) - pentestercrab
http://xn--thibaud-dya.fr/openbsd_softraid.html
======
dimman
I think that almost every experienced Linux user has some secret love for *BSD
deep down, myself included. They just seem to get it right for the majority of
times.

------
akerro
Recently there are more and more BSD related news :)

~~~
danieldk
I think that's great. The BSD projects have been extremely undervalued.
OpenBSD provides OpenSSH, LibreSSL, etc. FreeBSD provided a lot code to Mac OS
X and used used in a some commercial products (Playstation's OS, Juniper
routers, etc.).

The BSDs have worked on shoestring budgets. Let's hope this attention leads to
more sponsorship!

~~~
akerro
And DragonFlyBSD provides HAMMER
[https://www.dragonflybsd.org/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.freebsdfoundation.org/donate/)

[https://www.openbsd.org/donations.html](https://www.openbsd.org/donations.html)

[https://www.dragonflybsd.org/donations/](https://www.dragonflybsd.org/donations/)

~~~
CJefferson
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 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!

~~~
beagle3
> 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.

~~~
CJefferson
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.

------
0x0
What's with this highlighted comment? Are you guaranteed corruption on every
half terabyte?

> "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."

~~~
nnn
Based on my reading of the article, it says that OpenBSD always uses the same
key, scr_key[0], and does not implement the use of different keys for
different parts of the disk. I haven't looked at the OpenBSD source code to
confirm this, though.

------
ktta
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

~~~
RJIb8RBYxzAMX9u
It's Punycode.

[https://en.wikipedia.org/wiki/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](https://en.wikipedia.org/wiki/IDN_homograph_attack)

