[gentoo-amd64] Using encrypted swap via cryptsetup-luks on amd64

[gentoo-amd64] Using encrypted swap via cryptsetup-luks on amd64

[Adrian Middleton]

So I have been using this same setup perfectly for like a year until
yesterday when I updated my system and rebooted to find that init was
hanging when trying to mount my swap. It appears the problem occured
because of something to do with a cryptsetup upgrade. I forgot to run
dispatch-conf after the system update and found that my system would hang very early in init with 'Warning: exhausting read requested, but key file is not a regular file, function might never return'
and an invalid variable 'type=luks' error. So I boot the live cd and mount the root fs and
run dispatch-conf and find that indeed there is no longer a 'type'
variable. After modifying the new /etc/conf.d/cryptfs to match my old
one as much as i could and carefully reading the comments, I rebooted
again only to find that the 'invalid variable' error was gone but the
error about an exhausting read persisted

According to the new cryptfs, options '-c aes -h sha1 -d /dev/urandom' are used with swap by default but the command echo'd during boot reflects this, but also appears to use the 'luksOpen' action with the command. when i issued the command from the shell prompt, it didn't prompt for a pass and failed just as i'm assuming it did during boot and gave the same error. i should think the command issued by init would be one that uses the 'create' action rather than 'luksOpen', since that is what is specified in most of the documentation on creating encrypted swaps i have read. when i do it manually with 'create' rather than 'luksOpen' it still works fine so i don't know what is going on with the new script(s) that reference this file. the new /etc/conf.d/cryptfs says that the script should autodetect if it is a LUKS partition or not but apparently it doesn't do a very good job... or i'm missing something really obvious somehow

any help regarding this would be greatly appreciated. here is a copy of my new /etc/conf.d/cryptfs options:

## swap
# Swap partitions. These should come first so that no keys make their
# way into unencrypted swap.
# If no options are given, they will default to: -c aes -h sha1 -d /dev/urandom
# If no makefs is given then mkswap will be assumed
swap=crypt-swap 
source='/dev/sda1' 
#options='-c aes -h 256 -d /dev/urandom'

## /home with passphrase
target=home
source='/dev/sda3'

Thanks in advance
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Duncan]

Adrian Middleton <lists@mentalcases.net> posted
20061021073901.3e81782e@trichrome.mentalcases.net, excerpted below, on 
Sat, 21 Oct 2006 07:39:01 -0400:

> So I have been using this same setup perfectly for like a year until
> yesterday when I updated my system and rebooted to find that init was
> hanging when trying to mount my swap. It appears the problem occured
> because of something to do with a cryptsetup upgrade. I forgot to run
> dispatch-conf after the system update and found that my system would hang
> very early in init with 'Warning: exhausting read requested, but key file
> is not a regular file, function might never return' and an invalid
> variable 'type=luks' error. So I boot the live cd and mount the root fs
> and run dispatch-conf and find that indeed there is no longer a 'type'
> variable.

You don't mention what version of that or baselayout you are using, and
I'm not running encrypted swap tho I've always thought it'd be nice to
setup /someday/, so I can't help directly.  However, running ~amd64, I've
discovered that it's wise to run emerge --pretend --changelog <package>
for packages such as baselayout and portage, every time they want to
update, just to get an idea what's changing and how it might affect me. 
It appears you didn't do this and were taken by surprise, particularly so
having forgotten to dispatch-conf or etc-update.

Anyway, I /did/ see some changes related to that in the last baselayout
updates IIRC.  I'd suggest you check bugzilla and see what's up.  If
there's not bugs filed on the issue already, perhaps you'll want to file
one, as the number of folks using that feature is going to be relatively
small, and maybe you're the first to run into the issue.  I know I use a
couple corner-case modules (mainly macchanger) and a couple local
modifications (to the checkroot and checkfs scripts), and have been the
first to come across issues in the updates and file bugs on them, a few
times.

It's worth keeping in mind the distinction between ordinary packages where
Gentoo just packages and distributes the work of upstream, and packages
such as portage and baselayout where Gentoo /is/ upstream.  On the former,
by the time something gets into ~arch, it has normally been reasonably
well tested upstream and is a stable candidate.  On the latter, Gentoo's
own development, ~arch /is/ the testing altho they still aren't going to
release stuff that isn't working for them.  Thus, an ~arch user anyway can
expect to come across a few issues the devs didn't have the config to
test, from time to time.  Because these packages are by definition core
Gentoo packages as well, it's worth taking a bit of extra time to find out
just what is changing and be prepared for issues in those areas as one
upgrades, from time to time.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> I'm not running encrypted swap tho I've always thought it'd be nice to
> setup /someday/, so I can't help directly.  

I just run the following script from local.start.  I forget where I
found it online.  Obviously change the swapdevice variable!

Honestly, my guess is that it is overly paranoid.  You could probably
eliminate most of the steps this script takes, but it runs in only a
second or two so it isn't a big deal.  I would leave in the bit that
zeros the start of the encrypted swap partition - it probably helps to
keep mkswap from getting confused.

Not sure what the fancy scripts that are being discussed do, but this is
plenty good for me, and I'm sure Duncan could get this running in about
15 seconds...

#!/bin/sh
# Run this script somewhere in your startup scripts _after_ random
# number generator has been initialized and /usr has been mounted.
# (md5sum, uuencode, tail and head programs usually reside in /usr/bin/)

# encrypted swap partition
SWAPDEVICE=/dev/hda3

# loop device name
LOOPDEV=/dev/loop6

MD=`dd if=${SWAPDEVICE} bs=4k count=10 2>/dev/null | md5sum`
for X in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ; do
    dd if=/dev/zero of=${SWAPDEVICE} bs=4k count=10 conv=notrunc 2>/dev/null
    sync
done
UR=`dd if=/dev/urandom bs=18 count=1 2>/dev/null \
    | uuencode -m - | head -n 2 | tail -n 1`
echo ${MD}${UR} | losetup -p 0 -e aes-cbc-256  ${LOOPDEV} ${SWAPDEVICE}
MD=
UR=
dd if=/dev/zero of=${LOOPDEV} bs=4k count=10 conv=notrunc 2>/dev/null
sync
mkswap ${LOOPDEV}
sync
swapon ${LOOPDEV}
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFOuTeG4/rWKZmVWkRAvh/AJ9m/TppQ4w+kFEtjRgqRqBXrW0HSgCffycx
v1aYQi+49/PX9GBTi8Z5kxk=
=X4Km
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Jason Booth]

On Saturday 21 October 2006 21:26, Richard Freeman wrote:
> Duncan wrote:
> > I'm not running encrypted swap tho I've always thought it'd be nice to
> > setup /someday/, so I can't help directly.
>
> I just run the following script from local.start.  I forget where I
> found it online.  Obviously change the swapdevice variable!
>
> Honestly, my guess is that it is overly paranoid.  You could probably
> eliminate most of the steps this script takes, but it runs in only a
> second or two so it isn't a big deal.  I would leave in the bit that
> zeros the start of the encrypted swap partition - it probably helps to
> keep mkswap from getting confused.
>
> Not sure what the fancy scripts that are being discussed do, but this is
> plenty good for me, and I'm sure Duncan could get this running in about
> 15 seconds...

Yeah this script has worked fine for me for like 5 years except for one thing: 

I can't find which gentoo package contains uuencode(installed 
uucp,uulib,uudeview and googled to no avail).

>
> #!/bin/sh
> # Run this script somewhere in your startup scripts _after_ random
> # number generator has been initialized and /usr has been mounted.
> # (md5sum, uuencode, tail and head programs usually reside in /usr/bin/)
>
> # encrypted swap partition
> SWAPDEVICE=/dev/hda3
>
> # loop device name
> LOOPDEV=/dev/loop6
>
> MD=`dd if=${SWAPDEVICE} bs=4k count=10 2>/dev/null | md5sum`
> for X in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ; do
>     dd if=/dev/zero of=${SWAPDEVICE} bs=4k count=10 conv=notrunc
> 2>/dev/null sync
> done
> UR=`dd if=/dev/urandom bs=18 count=1 2>/dev/null \
>
>     | uuencode -m - | head -n 2 | tail -n 1`
>
> echo ${MD}${UR} | losetup -p 0 -e aes-cbc-256  ${LOOPDEV} ${SWAPDEVICE}
> MD=
> UR=
> dd if=/dev/zero of=${LOOPDEV} bs=4k count=10 conv=notrunc 2>/dev/null
> sync
> mkswap ${LOOPDEV}
> sync
> swapon ${LOOPDEV}
Thanks,
Jason

-- 
 gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Jason Booth]

On Saturday 21 October 2006 23:16, Jason Booth wrote:
> On Saturday 21 October 2006 21:26, Richard Freeman wrote:
> > Duncan wrote:
> > > I'm not running encrypted swap tho I've always thought it'd be nice to
> > > setup /someday/, so I can't help directly.
> >
> > I just run the following script from local.start.  I forget where I
> > found it online.  Obviously change the swapdevice variable!
> >
> > Honestly, my guess is that it is overly paranoid.  You could probably
> > eliminate most of the steps this script takes, but it runs in only a
> > second or two so it isn't a big deal.  I would leave in the bit that
> > zeros the start of the encrypted swap partition - it probably helps to
> > keep mkswap from getting confused.
> >
> > Not sure what the fancy scripts that are being discussed do, but this is
> > plenty good for me, and I'm sure Duncan could get this running in about
> > 15 seconds...
>
> Yeah this script has worked fine for me for like 5 years except for one
> thing:
>
> I can't find which gentoo package contains uuencode(installed
> uucp,uulib,uudeview and googled to no avail).
Nevermind I just found it: sharutils

>
> > #!/bin/sh
> > # Run this script somewhere in your startup scripts _after_ random
> > # number generator has been initialized and /usr has been mounted.
> > # (md5sum, uuencode, tail and head programs usually reside in /usr/bin/)
> >
> > # encrypted swap partition
> > SWAPDEVICE=/dev/hda3
> >
> > # loop device name
> > LOOPDEV=/dev/loop6
> >
> > MD=`dd if=${SWAPDEVICE} bs=4k count=10 2>/dev/null | md5sum`
> > for X in 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 ; do
> >     dd if=/dev/zero of=${SWAPDEVICE} bs=4k count=10 conv=notrunc
> > 2>/dev/null sync
> > done
> > UR=`dd if=/dev/urandom bs=18 count=1 2>/dev/null \
> >
> >     | uuencode -m - | head -n 2 | tail -n 1`
> >
> > echo ${MD}${UR} | losetup -p 0 -e aes-cbc-256  ${LOOPDEV} ${SWAPDEVICE}
> > MD=
> > UR=
> > dd if=/dev/zero of=${LOOPDEV} bs=4k count=10 conv=notrunc 2>/dev/null
> > sync
> > mkswap ${LOOPDEV}
> > sync
> > swapon ${LOOPDEV}
>
> Thanks,
> Jason
>
> --
>  gpg public key:
> http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc

-- 
 gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Francesco Talamona]

On Sunday 22 October 2006 07:16, Jason Booth wrote:
> I can't find which gentoo package contains uuencode(installed
> uucp,uulib,uudeview and googled to no avail).

[08:19] [sko@aemaeth:~]$ equery belongs /usr/bin/uuencode
[ Searching for file(s) /usr/bin/uuencode in *... ]
app-arch/sharutils-4.2.1-r11 (/usr/bin/uuencode)

Ciao
	Francesco

-- 
Linux Version 2.6.18-gentoo-r1, Compiled #1 PREEMPT Wed Oct 18 22:52:55 
CEST 2006
One 2.2GHz AMD Athlon 64 Processor, 2GB RAM, 4408.88 Bogomips Total
aemaeth
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Jason Booth]

On Sunday 22 October 2006 00:21, Francesco Talamona wrote:
> On Sunday 22 October 2006 07:16, Jason Booth wrote:
> > I can't find which gentoo package contains uuencode(installed
> > uucp,uulib,uudeview and googled to no avail).
>
> [08:19] [sko@aemaeth:~]$ equery belongs /usr/bin/uuencode
> [ Searching for file(s) /usr/bin/uuencode in *... ]
> app-arch/sharutils-4.2.1-r11 (/usr/bin/uuencode)
only works if already installed ;)

lazybird ~ # equery belongs /usr/bin/uuencode
[ Searching for file(s) /usr/bin/uuencode in *... ]
lazybird ~ #                                 

>
> Ciao
> 	Francesco
>
> --
> Linux Version 2.6.18-gentoo-r1, Compiled #1 PREEMPT Wed Oct 18 22:52:55
> CEST 2006
> One 2.2GHz AMD Athlon 64 Processor, 2GB RAM, 4408.88 Bogomips Total
> aemaeth

-- 
 gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc
-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 1142 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason Booth wrote:
> On Sunday 22 October 2006 00:21, Francesco Talamona wrote:
>> On Sunday 22 October 2006 07:16, Jason Booth wrote:
>>> I can't find which gentoo package contains uuencode(installed
>>> uucp,uulib,uudeview and googled to no avail).
>> [08:19] [sko@aemaeth:~]$ equery belongs /usr/bin/uuencode
>> [ Searching for file(s) /usr/bin/uuencode in *... ]
>> app-arch/sharutils-4.2.1-r11 (/usr/bin/uuencode)
> only works if already installed ;)
> 
> lazybird ~ # equery belongs /usr/bin/uuencode
> [ Searching for file(s) /usr/bin/uuencode in *... ]
> lazybird ~ #                                 
> 

Portage file search is your friend:

http://www.rommel.stw.uni-erlangen.de/~fejf/cgi-bin/pfs-web.pl

If you have a diverse set of packages try running the client to improve
the index (not that it needs all that much improvement).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFO10GG4/rWKZmVWkRAnkBAJ49aKR6u3/g/XNiET3xE8Ybs5antQCgwDtF
zZjC4uxSRE0tJ+CT7v6frPk=
=WTTQ
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Jason Booth]

On Sunday 22 October 2006 05:59, Richard Freeman wrote:
> Portage file search is your friend:
>
> http://www.rommel.stw.uni-erlangen.de/~fejf/cgi-bin/pfs-web.pl
>
> If you have a diverse set of packages try running the client to improve
> the index (not that it needs all that much improvement).
Thanks. Yeah I thought I had forgotten a command to do it, but appearently 
not..

-Jason
-- 
 gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Duncan]

Richard Freeman <rich@thefreemanclan.net> posted
453AE4DE.4090708@thefreemanclan.net, excerpted below, on  Sat, 21 Oct 2006
23:26:22 -0400:

> Not sure what the fancy scripts that are being discussed do, but this is
> plenty good for me, and I'm sure Duncan could get this running in about
> 15 seconds...

Well, there's could, and there's groking what it's actually doing, in case
there's a problem and to ensure it's actually encrypting it.  (I
/seriously/ hope that mention of uuencode doesn't mean they're using /it/
to "encrypt", for instance.  A quick look say they aren't, but that
doesn't tell me what's actually going on yet, either.)  If I'm going to be
running encrypted swap, I'm going to need to know all about what I'm using
to encrypt it (losetup here, it seems), and how that plays with my
four-way striped swap (a four gig partition on each of my four SATA
drives, all set pri=1 so the kernel stripes it for performance), among
other things. If I can't rest assured it's working well, why bother?

Actually, what I could do now that I have 8 gig of RAM is turn off
swap again, wipe the partitions, and simply leave swap off.  Only if they
ever get suspend to disk working semi-reliably... and I do have /tmp
(which is my $PORTAGE_TMPDIR as well) mounted as a tmpfs, and could
theoretically go into swap with multiple parallel merges tho I have it set
to 5 gig max, which would still give me 3 gig of memory to work at a maxed
/tmp, even with 0 swap.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Richard Freeman]

[-- Attachment #1: Type: text/plain, Size: 3586 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Duncan wrote:
> 
> Well, there's could, and there's groking what it's actually doing, in case
> there's a problem and to ensure it's actually encrypting it.  (I
> /seriously/ hope that mention of uuencode doesn't mean they're using /it/
> to "encrypt", for instance.  A quick look say they aren't, but that
> doesn't tell me what's actually going on yet, either.)  

Ok, in a nutshell:

1.  Generate MD5 hash of first 40k of previous swap volume (essentially
a source of entropy).  In my opinion it isn't needed but probably
couldn't hurt.

2.  Wipe that 40k 20 times - just so nobody can figure out what that
hash might have been later.

3.  Generate a random encryption key (WHOA - why on earth is that script
using urandom for this - it only pulls 18 bytes - I just changed it to
/dev/random in mine (more secure in the event the entropy pool gets low
- - although normally they are the same)).  For those not in the know,
/dev/random blocks if it runs out of entropy, but /dev/urandom just
gives out a less random value.  If you need 50MB of random data you have
to use urandom if you don't want to freeze the system for 12 hours, but
for 18 bytes we can afford to wait for quality data.

4.  /dev/(u)random dumps binary data - losetup wants something more sane
as a key, so uuencode is used to convert to text.  No source of
compromise here - the original data was random so the uuencoded data is
still random (it is now constrained in potential output values, but is
longer which compensates).

5.  Set up the loop device using the output of steps 1 and 4
concatenated as an encryption key (losetup will generate a SHA-512 key
from the text key and use that for actual encryption).

6.  Wipe out the variables containing the two key components (probably
doesn't accomplish much).  The keys will be in RAM somewhere for as long
as the swap is mounted and only root can hunt for the keys either way.

7.  Zero the start of the encrypted loop device - mainly just to make
mkswap happy in case the device ends up looking like some other type of
partition.

8.  Create and use the swap device.


> If I'm going to be
> running encrypted swap, I'm going to need to know all about what I'm using
> to encrypt it (losetup here, it seems), and how that plays with my
> four-way striped swap (a four gig partition on each of my four SATA
> drives, all set pri=1 so the kernel stripes it for performance), among
> other things. If I can't rest assured it's working well, why bother?
> 

I'd just make SWAPDEVICE and LOOPDEV command-line parameters and then
call the script 4 times.

> swap again, wipe the partitions, and simply leave swap off.  Only if they
> ever get suspend to disk working semi-reliably... 

Not sure encrypted swap will play well with suspend to disk.  Somehow
when the system wakes up it needs to find out what the encryption key
actually was, otherwise the loop device can't be reactivated.  Now, it
is possible that the kernel will just write the key to disk somewhere,
but this defeats much of the security of an encrypted swap device (where
after a reboot the swap space is impossible to read without a brute
force attack on AES-CBC).  If the key isn't written to disk the kernel
will boot and look around and not see any valid swap partitions on the
disk at all.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFO2EGG4/rWKZmVWkRAsRsAKCoF3LGq2Qw+jvQI6W+1i5A0i2hXwCgifEl
oWpJqZG0t7txICyhZhQhu/Q=
=AdpP
-----END PGP SIGNATURE-----

[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3875 bytes --]

Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Jason Booth]

On Sunday 22 October 2006 06:16, Richard Freeman wrote:
> I'd just make SWAPDEVICE and LOOPDEV command-line parameters and then
> call the script 4 times.
or drop a for loop into it...

I don't know much about raid, but if it's treated in /dev as a single device, 
you may just be able to replace it and go. 

May be overly paranoid, but writing encrypted data multiple times could help 
someone to guess what certain file is and make an attack on the encryption 
easier. I use ext2 for my encrypted loops so there's no journal as well. 
Although the power fails sometimes, and can be a pain to fsck, i haven't lost 
anything yet.

>
> > swap again, wipe the partitions, and simply leave swap off.  Only if they
> > ever get suspend to disk working semi-reliably...
>
> Not sure encrypted swap will play well with suspend to disk.  Somehow
> when the system wakes up it needs to find out what the encryption key
> actually was, otherwise the loop device can't be reactivated.
Last time i tried S2D, albeit a couple of years now, the loops all had to be 
re-mounted after wake(and of course fsck'd)
> Now, it 
> is possible that the kernel will just write the key to disk somewhere,
> but this defeats much of the security of an encrypted swap device (where
> after a reboot the swap space is impossible to read without a brute
> force attack on AES-CBC).
I think key retention support in kernel may accomplish this
> If the key isn't written to disk the kernel 
> will boot and look around and not see any valid swap partitions on the
> disk at all. 

Also, it seems AES-CBC is the standard for swap.. at least per the loop-aes 
package that contained this script. Does anyone of a good benchmark list?

I found this but didn't see aes on it
http://www.eskimo.com/~weidai/benchmarks.html

-Jason
-- 
 gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Duncan]

Jason Booth <jbooth@hyperintelligent.net> posted
200610221115.22864.jbooth@hyperintelligent.net, excerpted below, on  Sun,
22 Oct 2006 11:15:22 -0600:

> On Sunday 22 October 2006 06:16, Richard Freeman wrote:
>> I'd just make SWAPDEVICE and LOOPDEV command-line parameters and then
>> call the script 4 times.
> or drop a for loop into it...
> 
> I don't know much about raid, but if it's treated in /dev as a single device, 
> you may just be able to replace it and go. 

The neat thing about swap is that the kernel stripes it on its own -- no
raid drivers needed.  You just mount the raid swap partitions and set all
the ones you want striped to the same priority (I use pri=1), and the
kernel will do the rest on its own.  If they are all the same size, great,
if not, it'll stripe them until the smallest one is gone then it'll stripe
the remainder, again all automatically.

(Striping means it writes a few bytes, maybe the standard half-kb
block tho in the case of swap tho I'm not sure, to the first device, then
the next block to the second, the third block to the third, etc.  Because
bus speed is far faster than physical disk write speed, with four disks by
the time you've sent the data to the fourth one, the first is pretty much
done actually writing it to disk and ready for more again, so the data is
written out and read in at bus speed rather than at bus speed until the
cache on the drive fills up or empties, then at drive speed.  The caveat
with pure striping, aka raid-0, is that while it's much faster, it's not
redundant at all, the "r" in "raid" isn't!  Thus if one disk goes out, you
lost what amounts to everything, tho of course a good data recovery place
can still recover say 3 out of every 4 blocks if it was a four-way stripe.
However, this isn't a problem as long as you don't need five-nines uptime
or the like -- if you want a bad drive to crash the system anyway, so you
know about it and can recover the non-raid-0 non-swap data on the other
drives due to the redundancy of the other raid formats.)

> May be overly paranoid, but writing encrypted data multiple times could help 
> someone to guess what certain file is and make an attack on the encryption 
> easier. I use ext2 for my encrypted loops so there's no journal as well. 
> Although the power fails sometimes, and can be a pain to fsck, i haven't lost 
> anything yet.

If one were using a non-striped raid, say raid-1 (mirrored), or raid-6
(striped minus two, which are parity, so a 4-way is 2-way striped plus two
parity, raid-6 allows you to lose any two of the drives), the data would
be redundant, but not in pure striped.  A redundant raid form swap might
be used where uptime is critical and hot-swap drives are used, so the
system could continue running after a drive crashed, while it was
hot-swapped out.  However, that's the big costly operation way of doing
things, not a hobbyist's way of doing things unless you are Mark
Shuttleworth or something, and going down to replace the drive is expected
here anyway, after which the swap could be reconfigured, so no big deal.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@gentoo.org mailing list

Re: [gentoo-amd64] Re: Using encrypted swap via cryptsetup-luks on amd64

[Jason Booth]

On Sunday 22 October 2006 06:16, Richard Freeman wrote:
> 3.  Generate a random encryption key (WHOA - why on earth is that script
> using urandom for this - it only pulls 18 bytes - I just changed it to
> /dev/random in mine (more secure in the event the entropy pool gets low
> - although normally they are the same)).  For those not in the know,
> /dev/random blocks if it runs out of entropy, but /dev/urandom just
> gives out a less random value.  If you need 50MB of random data you have
> to use urandom if you don't want to freeze the system for 12 hours, but
> for 18 bytes we can afford to wait for quality data.

Nice catch. At this point in booting we should have plenty of entropy in the 
random pool.  Would be wise to start service random a few steps back to make 
sure it's really random and not boot-sequence-pridictable-random, although 
the script is plenty paranoid.
>
> 4.  /dev/(u)random dumps binary data - losetup wants something more sane
> as a key, so uuencode is used to convert to text.  No source of
> compromise here - the original data was random so the uuencoded data is
> still random (it is now constrained in potential output values, but is
> longer which compensates).
I actually ran this script many times without uuencode, just passing the 
random string to losetup without any complaints. glad i have uuencode now 
though ;)

-Jason

-- 
 gpg public key: http://lazybird.hyperintelligent.net/~jbooth/jbooth_key.asc

-- 
gentoo-amd64@gentoo.org mailing list