Petersen wrote:
> Jari Ruusu wrote:
> > loop-AES-v3.0a mount and losetup can also read multi-key from file
> > descriptor specified with -p command line option.
>
> But don't I need gpg-keys then? Perhaps I misunderstood the concept of
> multi-key-v3, is the keys actually gpg-keys? Of course I want a secure
> system, but I also would like to avoid kB's of random ascii data for the
> case if they disappear, and only have my memorised password left (and
> the encrypted partition).
Loop encryption keys are stored in gpg encrypted message. All you need to do
is to memorize the passphrase that can decrypt the gpg message.
losetup/mount/gpg programs do the rest.
Any key directly derived from human memorizable passphrase is almost always
weak. High quality random keys in gpg encrypted message are much stronger.
If you insist on storing the key file on the same partition as encrypted
data, then you can write the key file data to beginning of the partition and
specify an offset for the loop device. This example uses /dev/hda999 as the
partition:
Fill partition with junk
head -c 15 /dev/urandom | uuencode -m - | head -n 2 | tail -n 1 \
| losetup -p 0 -e AES128 /dev/loop0 /dev/hda999
dd if=/dev/zero of=/dev/loop0 bs=4k conv=notrunc
losetup -d /dev/loop0
Put key file to beginning of partition
yes "" | dd of=/dev/hda999 bs=8192 count=1 conv=notrunc
head -c 2925 /dev/random | uuencode -m - | head -n 66 | tail -n 65 \
| gpg --symmetric -a | dd of=/dev/hda999 conv=notrunc
Put this line to /etc/fstab
/dev/hda999 /mnt999 ext3 defaults,noauto,loop=/dev/loop0,encryption=AES128,gpgkey=/dev/hda999,offset=8192 0 0
Create new encrypted file system
losetup -F -v /dev/loop0
mkfs -t ext3 /dev/loop0
losetup -d /dev/loop0
mkdir /mnt999
And then mount and unmount it
mount /mnt999
umount /mnt999
> So does the encrypted swap in fact use 65 random/"unknown" gpg-keys?
swapon program creates 65 random keys based on data from /dev/urandom and
old encrypted swap data from same partition. swapon program talks direcly to
loop driver without gpg doing anything.
> I suppose I can set a seed with 'losetup .. -S we23fef ...' or
> something? As the machine I want to encrypt is switched on and off every
> day, I will store gpg-keys and seed on hard disk or floppy (and put a
> copy 'somewhere safe').That equals security level 2) from your readme.
You are better off using one of the examples in the README or above example.
> The seed, being available to the attacker, is only good to force the
> attacter to discard his precomputed, nonseeded, dictionary list??
Yes. The seed prevents *pre*computed dictionary attacks.
> I understand that some file (all zeroes for example) will give identical
> encrypted blocks on the disk.
Nope. But weak IV computation can be exploited so that two different
plaintexts will result in same ciphertext.
> I found that 'hdparm -W 0 /dev/hdx' is necessary to switch off the
> write-cache (http://lwn.net/Articles/67223/). Perhaps you should add
> this to your README.
It depends whether the box gets its power from UPS or not. Write caching is
ok in the UPS powered case. It is exactly same issue on unencrypted case.
> Another thing I struggled with a while back, is the confusion around the
> cryptoloop/loop-aes that kernel 2.6.x contains. I thought your loop-AES
> equaled the kernel option, and supposed doing it 'your way' was getting
> obsolete after kernel 2.6.x integrated encryption in the kernel. I never
> got the 2.4.x-cryptoloop kernel patch to work, so I did it your way; it
> seems now that this is the superior method security wise.
Mainline cryptoloop is the one that is obsolete.
--
Jari Ruusu 1024R/3A220F51 5B 4B F9 BB D3 3F 52 E9 DB 1D EB E3 24 0E A9 DD
-
Linux-crypto: cryptography in and on the Linux system
Archive: http://mail.nl.linux.org/linux-crypto/
