Discussions about the GEOM framework and about implementations of GEOM modules ()

Volker | 14 Jan 2008 14:11

Re: Re: how-to: encryption + journaling (geli + gjournal)

On 12/23/-58 19:59, RW wrote:
> On Sun, 13 Jan 2008 23:42:07 +0100
> Volker <volker <at> vwsoft.com> wrote:
> 
>> For the archives (as I haven't found a nice how-to on this topic):
>>
>> A short how-to to get geli + gjournal running smoothly (the lazy way,
>> depending mostly on OS infrastructure, no script hacking needed).
>>
>> - set up your geli provider:
>> geli load
>> geli init /dev/ad0s1d # check geli(8) for this
>> geli attach /dev/ad0s1d
>> dd if=/dev/random of=/dev/ad0s1d.eli bs=1m # (use higher values bs=...
>> for faster operation)
> 
> It would probably be faster to fill /dev/ad0s1d from /dev/random before
> doing the geli init - there's no point in encrypting the random numbers.
> It would also ensure that the whole of ad0s1d is pre-filled, and not
> just the part accessible as ad0s1d.eli.

If you think it doesn't make sense or is a fault, please file a PR as
filling the data provider with random data has been taken from the
manpage geli(8).

Otherwise I'm considering this being a bike shed.

If you know it better, I'm wondering why you haven't written a how to
in the past?

(Continue reading)

headers

RW | 14 Jan 2008 22:15

Re: how-to: encryption + journaling (geli + gjournal)

On Mon, 14 Jan 2008 13:11:38 +0000
Volker <volker <at> vwsoft.com> wrote:

> On 12/23/-58 19:59, RW wrote:

> > It would probably be faster to fill /dev/ad0s1d from /dev/random
> > before doing the geli init - there's no point in encrypting the
> > random numbers. It would also ensure that the whole of ad0s1d is
> > pre-filled, and not just the part accessible as ad0s1d.eli.
> 
> If you think it doesn't make sense or is a fault, please file a PR as
> filling the data provider with random data has been taken from the
> manpage geli(8).

It's only an example.

> 
> Otherwise I'm considering this being a bike shed.
> 
> If you know it better, I'm wondering why you haven't written a how to
> in the past?

There's no need to be rude, I'm only trying to help.

In my experience writing from /dev/random to a raw partition is almost
twice as fast as writing to an .eli device - essentially it's single
verses double encryption. 

I recently filled a raw partition on a 500GB drive and it took 6 hours,
doing it on the eli device would have taken about 11 hours. I think

(Continue reading)

headers

Christian Baer | 27 Jan 2008 00:20

Re: how-to: encryption + journaling (geli + gjournal)

On Mon, 14 Jan 2008 21:15:37 +0000 RW wrote:

> There's no need to be rude, I'm only trying to help.

You guys are both a little sensitive, aren't you? 

> In my experience writing from /dev/random to a raw partition is almost
> twice as fast as writing to an .eli device - essentially it's single
> verses double encryption. 

True, this *is* faster. But there is also a reason for encrypting the
random numbers - although I would probably use zeros which will look
pretty much like random numbers on a disk once they are encrypted.

If you use a checksum (geli init -a) geli will need to know what is on the
disc. So you actually have to fill the disc through geli before you can
use it. If you don't do this you will get lots of errors stating that the
data on the disc is corrupt.

I guess the reason why blanking a disc with encrypted random numbers is
the double entropy and the fact that there are cases where you have to
blank a disc through geli.

Regards,
Chris