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.
Ok, so no gpg-key=no access(?) I am afraid I'll lose the gpg-keys, the human element is often the biggest threat.
What about data corruption like zip-files suffers?
"But doesn't this give easier corruption; for example, zip-files gets easily destroyed because byte N depends of bytes 0 to N-1, and if byte N gets altered, N to Nlast are wrong."
- -
I don't always treat my server nicely, sometimes it is shut down on the power switch. Can my encrypted disk (ext3 on top of device backed loop) survive such treatment no worse than a regular ext3?
I'll play more with loop-AES before moving data permanently to the encrypted disk, I'll also try your watermark examples.
I want to use encryption mainly because my data is no-one elses business. If someone send me an illegal mp3-file, I also want to be guarded against the copyright-police, which is pretty aggressive in Danmark.
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.
- Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
