Re: encrypting with loop-AES-v3.0a and no gpg-key doesn't give 'multi-key-v3'exceptfor swap

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jari Ruusu wrote:
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/


[Index of Archives]     [Kernel]     [Linux Crypto]     [Gnu Crypto]     [Gnu Classpath]     [Netfilter]     [Bugtraq]
  Powered by Linux