Re: Full disk encryption without a boot partition

[mhca12 <mhca12@xxxxxxxxx>]

On Fri, Dec 28, 2012 at 8:48 AM, Alex Hornung <alex@alexhornung.com> wrote:
> On 27/12/12 22:40, mhca12 wrote:
>> On Thu, Dec 27, 2012 at 11:00 PM, Alex Hornung <alex@alexhornung.com> wrote:
>>> On 27/12/12 22:13, mhca12 wrote:
>>>> On Thu, Dec 27, 2012 at 10:08 PM, Alex Hornung <alex@alexhornung.com> wrote:
>>>>> On 26/12/12 22:19, mhca12 wrote:
>>>>>> Are there any plans or is there already support for full
>>>>>> disk encryption without the need for a boot partition?
>>>>>
>>>>> No, the userland tool that sets up the decryption of the root partition,
>>>>> as well as the kernel and modules need to be somewhere that is not
>>>>> encrypted - otherwise the boot loader would need to support the disk
>>>>> encryption.
>>>>
>>>> Seems like OpenBSD 5.2's bootloader can do that.
>>>> Any idea how they did it?
>>>
>>>  I didn't say that it's impossible, I just stated what would be
>>> required. There are no plans to do any such thing in DragonFly BSD, as
>>> there is pretty much no point. Doing it in any other way than with the
>>> separate /boot partition overcomplicates everything by an order of
>>> magnitude (since, for example, the setup cannot occur in userland
>>> anymore) for no real benefit.
>>
>> Sorry that I wasn't precise. I meant to say I find it hard to believe that
>> OpenBSD extended the bootloader to do decryption.
>> Your stated reasons make a lot of sense and I will try to find out
>> how it works in OpenBSD because I'm curious.
>
> I digged around a bit this morning out of interest. It seems a good
> chunk of cryptography was added to libstand, which, afaict, is what the
> bootloader uses - pbkdf2, AES, AES-XTS, SHA1, HMAC-SHA1.
>
> Those components are indicative of disk encryption - pbkdf2 will derive
> a key from your passphrase, AES-XTS is the nowadays preferred block
> cipher (and mode) for disk encryption, HMAC-SHA1 provides authenticated
> message integrity.
>
> That said, I haven't found much else in the bootloader code except some
> rudimentary softraid support. From a short look I'd say pieces are still
> missing (or maybe I've just missed them), but there is definitely some
> work on extending the OpenBSD bootloader to support full disk encryption.

The cited building blocks look enough to support softraid crypto
volumes afaics. Thanks for the research.

> That said and going back to DragonFly - our encryption scheme is much
> more flexible than OpenBSD's. The in-kernel part is almost completely
> generic, and userland tools provide the knowledge about the header for
> LUKS (cryptsetup) and TrueCrypt (tcplay), for example. We also support a
> large number of block ciphers, IV generation schemes, etc, as required
> by LUKS and tcplay.

I've always wondered how well tested and supported it is to
'cryptsetup luksFormat' a volume on Linux and then use
the same volume on both dfly and linux. Given that there's
a also luks loader for Windows, this seems like a big advantage
in favor of dfly out of the BSDs. What do you think?

> Supporting everything in the bootloader would be a lot of work, and I
> simply don't see the benefit. There is nothing wrong with having an
> unencrypted /boot partition - and you could in principle use an external
> /boot partition on, say, a USB stick.

The biggest issue I have with full disk encryption on Linux is
the requirement for initrd (initial ramdisk) and that you cannot
use a no-kernel-modules kernel. Someday I will research this
and find out if it cannot be avoided.