markus reichelt, June 2007
v0.4.1, last modified: 2010-08-14, status: actively maintained
This represents the FAQ section of the text. It is divided into five sections: Help, Security, Compatibility, Tuning and Tweaking, and Misc.
Don't forget to also consult
[top]
While digging through the mailing list archive I found some topics worth mentioning. So, if your Q/A concerns loop-AES and you think the community can benefit from it, please feel free to mail me in plain text only to the address listed at the bottom of this page (encypted mail is most welcome). I need help with this. Also, in case you don't want to be mentioned please explicitly state so - else I give credit with name/pseudo/date.
Since this procedure somehow doesn't seem to work the way it was intended to (a year has passed and not just a single contribution was sent in) I'm just going to continue to add relevant postings to the mailinglist as I see fit.
[faq]
With such a setup no partition-table is needed. What matters are losetup parameters -s (for size) and -o (for offset). Both have to be specified in bytes. The following excerpt from Jari's mail uses typical sector size of 512 bytes; in case you use exotic sector sizes, you have to adapt accordingly.
Units = sectors of 512 bytes, counting from 0 Device Boot Start End #sectors Id System /dev/hda1 * 63 48194 48132 83 Linux /dev/hda2 48195 11245499 11197305 83 Linux /dev/hda3 11245500 12273659 1028160 82 Linux swap And if you were to set up above three partitions as encrypted loop devices, then you could issue these losetup commands: losetup -e AES128 -K foo1.gpg -o @32256 -s 24643584 /dev/loop1 /dev/hda losetup -e AES128 -K foo2.gpg -o @24675840 -s 5733020160 /dev/loop2 /dev/hda losetup -e AES128 -K foo3.gpg -o @5757696000 -s 526417920 /dev/loop3 /dev/hda Offset and sizelimit need to be specied in bytes. Offset is partition start * 512, and sizelimit is #sectors * 512. The @ character in front of offset is needed to remove the offset from IV computations. For encrypted root, you can specify -o and -s losetup options to build-initrd.sh script if you redefine the meaning of PSEED option. Like this: CRYPTROOT=/dev/hda PSEED="-o @32256 -s 24643584" Normal file system mounts can use offset= and sizelimit= mount options in /etc/fstab file. Mount program understands them, but swapon program does not. So, for partition-table-less encrypted swap you must use losetup program with -o and -s options.
[source]
[faq]
It protects against identical ciphertexts leaking information. See this quote:
When sector data is encrypted or decrypted, position information within a partition or device is used in IV computation and in multi-key mode to also to select the encryption key. This provides reasonable guarantee that when same data is written to more than one sectors, ciphertexts will be different and attacker observing ciphertexts can't find out what plaintext sectors contain identical data. If same key file is used to encrypt more than one file system, there is a danger that same data + same encryption key + same position info will result in identical ciphertexts. Examples: (A) losetup -e AES128 -K foo1.gpg /dev/loop1 /dev/hda1 (B) losetup -e AES128 -K foo2.gpg /dev/loop2 /dev/hda2 (C) losetup -e AES128 -K foo3.gpg /dev/loop3 /dev/hda3 (D) losetup -e AES128 -K foo1.gpg -o @32256 -s 24643584 /dev/loop1 /dev/hda (E) losetup -e AES128 -K foo2.gpg -o @24675840 -s 5733020160 /dev/loop2 /dev/hda (F) losetup -e AES128 -K foo3.gpg -o @5757696000 -s 526417920 /dev/loop3 /dev/hda (G) losetup -e AES128 -K foo1.gpg -o 32256 -s 24643584 /dev/loop1 /dev/hda (H) losetup -e AES128 -K foo2.gpg -o 24675840 -s 5733020160 /dev/loop2 /dev/hda (I) losetup -e AES128 -K foo3.gpg -o 5757696000 -s 526417920 /dev/loop3 /dev/hda In examples (A), (B), (C), (D), (E), and (F), first loop device sector is encrypted using position info 0, second sector using position info 512, third sector using position info 1024, and so on. In example (G) first loop device sector is encrypted using position info 32256, second sector using position info 32256+512, third sector using position info 32256+1024, and so on. In example (H) first loop device sector is encrypted using position info 24675840, second sector using position info 24675840+512, third sector using position info 24675840+1024, and so on. In example (I) first loop device sector is encrypted using position info 5757696000, second sector using position info 5757696000+512, third sector using position info 5757696000+1024, and so on. Examples (A), (B), (C), (D), (E), and (F) must use different key files to avoid identical ciphertexts. Examples (G), (H), and (I) can use same key file because they never use same position info for IV computation. > Oh and why is the first partition starting at sector 63? Because I losetup'ed file systems that were originally created as partitions, but this time using partitionless full device. Most disk partitioning software that uses MSDOS style partitions leaves first track of first cylinder as unused. That is because the Master-Boot-Record and partition table are in first sector of first cylinder.
[source]
[faq]
No it isn't, but you can use it via
make KEYSCRUB=y
You can enable VIA padlock support via
make PADLOCK=y
Or you can just edit the Makefile so that lines 56 and 57 look like this:
KEYSCRUB:=y PADLOCK:=y
With such a Makefile you don't need to worry about forgetting make parameters. Just running make will do.
Note: In light of the cold-boot attack using keyscrubbing is not recommended.
The cold-boot attack is far more practical than the attack keyscrubbing tries to prevent (Data Remanence in Semiconductor Devices), and it is even stated in the paper that using keyscrubbing actually helps the attacker to recover the key from a RAM image (§7,p12).
[source]
[faq]
No it isn't. It's only available for the AES cipher; it would require significant rewriting of cipher implementations. (read: It will stay that way.)
[source]
[faq]
The loop device was set up "hard" in ro mode and does not permit changing its mode to rw. Either set it up in rw mode first (then change to ro mode) or set up the loop device directly via losetup (omitting the -r option, of course).
[source]
[faq]
If you want to use a plain loop-aes keyfile (without invoking gpg), use this mount syntax (man 8 mount):
mount -p 3 -t ext3 /dev/hda666 /mnt/foo \
^ ^ ^
-o loop=/dev/loop666,encryption=AES128 3</home/secret1
^ ^ ^ ^ ^ ^ ^ ^
[source]
Or you can use the new option "cleartextkey", see here for more details.
[faq]
This applies to multi-key (v2/v3) setups; just decrypt the gpg-protected keyfile and encrypt it again using a new passphrase:
gpg --decrypt </boot/rootkey.gpg | \ ( sleep 60; gpg -a --symmetric > /boot/new.gpg )
Then replace the old keyfile with the new one.
If you are using a single-key setup you have to re-encrypt your data anyway, so best grab that neat opportunity to switch to a v3 key setup.
[source]
In case you use on-disk keys, residing within the first 8192 bytes of a partition/device, apply this procedure:
1) Copy the existing keys to a temporary file (in case something goes wrong):
dd if=/dev/hda666 of=old.keys bs=512 count=16
2) Re-encrypt the keys:
gpg -d old.keys | (sleep 10; gpg -c -o new.keys)
3) Copy the newly re-encrypted keys back to the device:
dd if=new.keys of=/dev/hda666 conv=notrunc
[thanks to John Fitzgerald]
[faq]
For a protected keyfile, use this:
gpg --no-mdc-warning -q -o - keyfile.gpg | ssh user@remotehost \ "/sbin/losetup -p 0 -e AES128 /dev/loop666 /dev/hda666" 2>/dev/null
For an unprotected keyfile you can use this:
cat keyfile | ssh user@remotehost \ "/sbin/losetup -p 0 -e AES128 /dev/loop666 /dev/hda666" 2>/dev/null
Be aware that both examples do not show any ssh output. You might want to omit the redirect to null device. And losetup needs to be setuid root on the remote box, if you use ssh as ordinary user.
[faq]
The more relevant details the better:
1) bootloader configuration 2) build-initrd.sh configuration 3) full kernel configuration, compressed 4) /etc/fstab contents 5) which device are you trying to boot from? 6) distribution used 7) which loop-AES version are you using? 8) are you using a loop-AES package or your own source compile? 9) output of losetup -a 10) modinfo loop, any dmesg output of loop 11) ...
You don't need to provide all that info - just the parts relevant to your system.
[source]
[faq]
You can't, according to a comment in the build-initrd.sh script: For root encryption the loop device number has to be a single character only, even if max_loop is greater than the default value of 8 (0..7).
In case you choose loop device number 7 for root encryption be aware that loop-AES uses this device number by default for temp operations. You'd have to adapt both variables TEMPLOOPINDEX (in build-initrd.sh; used to create initrd image) and TLD (in Makefile; for running make tests) to use a different number.
[faq]
Modern libata drivers in linux kernel set up IDE drives as SCSI devices. Running build-initrd.sh script on such a system fails if you use such a (CD/DVD) device as BOOTDEV and/or CRYPTROOT; the old device node name scd is not used anymore these days, and build-initrd.sh script looks for it only. You can apply this patch or manually add the following line right under the entry for the scd device node name:
maybeMakeDiskNode sr 11 0 0
This applies to loop-AES versions up to 3.2a. You might run into this also if you are using native SCSI devices.
[source]
[faq]
With the stock version of loop-AES initrd building script that is possible by using EXTRAVERSION in each kernel's config. Another approach to achieve it:
An example: Say you have an old pIII used as linux router, a laptop with a Banias Pentium-M, a VIA Nehemiah backup server, and an Athlon64 desktop machine, all fully encrypted. You want to use the same kernel version on these systems, but fine-tune each system, and instead of having a separate boot-CD for each machine you just want one to be able to boot all your systems from a single boot-CD.
You can apply this patch that adds the keyword MODULEDIRECTORY to build-initrd.sh script (see comment); beware of possible 32bit/64bit binary pitfalls, though.
[source]
[faq]
You need to set GCC=gcc-3.3 in build-initrd.sh.
[source]
[faq]
No problems at all, works fine. Have a look at this thread.
[faq]
Slackware still uses util-linux switched to util-linux-ng with Slackware 12.1. Be aware that the original slackware util-linux-ng package (under slackware-xx.x/source/a/util-linux-ng/) includes certain patches, so be sure to apply them as well when installing loop-AES on a slackware system. Usually, only the one for UUID is of importance. Better check your setup nevertheless.
Have a look at this.
[faq]
So far the following distros include loop-AES:
Mail me if a distro is not listed here.
[faq]
Slackware does not include loop-AES and its kernels all have the loop module built-in. So you have to recompile your kernel to match loop-AES' requirement of completely disabling the vanilla loop module. Anyway, to make life a bit easier I created a package of util-linux-ng with loop-AES support for the upcoming Slackware 12.1 release. It is fully compatible to the stock Slackware package and can be found at my public Slackware builds repository. I provide packages for Slackware versions since 12.1 along with Slackbuild scripts, so you can adapt the scripts as you see fit (SBo script usage is recommended).
SlackBuilds.org now offers build scripts maintained by yours truly for:
I also offer pre-compiled packages for i486, i686, and x86_64:
All pre-compiled packages are signed with the key I also use for my slackbuilds, 0xCCEEF115 listed for reference in my GnuPG Key Signing Policy.
[faq]
In theory, yes. But the practical workaround is tricky, and it sadly won't work on a root-filesystem. The paper of the so-called "cold-boot attack" mentions a way of locating and reconstructing keys from a memory image. Unfortunately, the authors have not released a working programme to the public so far. they have, check http://citp.princeton.edu/memory/code/. It would help greatly in the case of root-filesystems, see this quote: (please note: text in bold italic reflects current status and has been adapted in the quote)
Jan Lühr wrote:
> I accidently deleted my loop-aes-keyfile (ironically it happened while
> backuping it)
> However, all loopdevices are mounted at the moment.
> Is there a way to restore my keyfile using the keys loaded into ram?
Encryption keys that are in kernel ram were hashed using one way hash and
are kept in expanded form. Unlike mainline cryptoloop, loop-AES
intentionally does not return the keys using an ioctl() call. Someone would
need to write a new kernel module to extract the data.
Plan A
~~~~~~
- Backup up your data
- Re-create the file system with new key file
- Restore from backup
Plan B
~~~~~~
- This only works for non-root file systems
- Edit /etc/mtab and remove loop mount option from old line:
/dev/hda7 /mnt ext2 rw,loop=/dev/loop0,gpgkey=/root/test1.gpg,encryption=AES128 0 0
^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
so that new line looks like this:
/dev/loop0 /mnt ext2 rw 0 0
^ ^ ^ ^ ^
- When umount program reads above /etc/mtab line, it does not find 'loop'
mount option there, and umount program will not automatically detach loop
device from backing partition, /dev/hda7 in above example.
- Unmount the file system using the _loop_ device, like this:
umount /dev/loop0
- Create new key file, like this:
head -c 3705 /dev/random | uuencode -m - | head -n 66 | tail -n 65 \
| gpg --symmetric -a >/root/test2.gpg
- Attach second loop device to same partition, like this:
losetup -e AES128 -K /root/test2.gpg /dev/loop1 /dev/hda7
- Now you should have two loop devices to same partition, /dev/loop0 using
old keys, and /dev/loop1 using new keys.
- Now re-encrypt that partition using 'dd' command reading from loop device
with old keys and writing to loop device with new keys, like this:
dd if=/dev/loop0 of=/dev/loop1 bs=1024k conv=notrunc
- And finally detach both loop devices from partition:
losetup -d /dev/loop0
losetup -d /dev/loop1
- Now you have new key file, and partition encrypted using keys from that
new key file.
[source]
[faq]
No big deal - in essence:
Basically the technique is to put logical volumes onto partitions, loop-AES loopbacks on these and file systems over the top.
Check out this gentoo howto.
[source]
Also, be sure to check out this post if you are using logical volumes on a multicore system.
[faq]
Bruce Schneier wrote in his blog about Hash Function Attacks, but loop-AES is safe to use according to Jari:
If you are worrying about security... The way MD5 is used in loop-AES is not vulnerable. Recent MD5 attacks need known state. Adversary does not have known state, nether before nor after adversary supplied data is processed. Loop-AES version 3 on-disk format uses 65th key (unknown to adversary) as MD5 input before adversary supplied data, and output end up being encrypted using AES (again, with a key unknown to adversary).
[source]
[faq]
See this explanation by Jari:
Following uses '|' to indicate concatenation. Arrays are 0-based.
Version 3 IV is computed as:
IV = MD5(key_table[64] | plaintext_bytes[16...511] | sector_number)
Version 2 IV is computed as:
IV = MD5(plaintext_bytes[16...511] | sector_number)
On version 3, each 512 byte sector is encrypted as:
K = key_table[sector_number & 63]
IV = MD5(key_table[64] | plaintext_bytes[16...511] | sector_number)
ciphertext_bytes[0...511] = CBC_ENCRYPT(K, IV, plaintext_bytes[0...511])
On version 3, each 512 byte sector is decrypted as:
K = key_table[sector_number & 63]
IV = ciphertext_bytes[0...15]
plaintext_bytes[16...511] = CBC_DECRYPT(K, IV, ciphertext_bytes[16...511])
IV = MD5(key_table[64] | plaintext_bytes[16...511] | sector_number)
plaintext_bytes[0...15] = CBC_DECRYPT(K, IV, ciphertext_bytes[0...15])
[faq]
Yes there is, but only for the first 2^41 bytes:
Mainline cryptoloop compatible mode, first 2^41 bytes:
aespipe -H unhashed2 -e AES256
kerneli.org cryptoloop compatible mode, first 2^41 bytes:
aespipe -H rmd160 -e AES256
Not sure about kerneli.org default key length.
Mainline cryptoloop uses only least significant 32 bits of 512-byte sector
number for IV computation, hence compatibility limit at 2^(32+9) bytes.
[source]
[faq]
Yes, mostly - the important part is. Exceptions are SIGKILL signals (kill -9), check:
--- Jari Ruusu wrote: > 1) gpg and losetup communicate using pipes. losetup sends passphrase to gpg > using a pipe. gpg sends decrypted key material to losetup using a pipe. > Last time I looked at mainline pipe code implementation, it did not > sanitize kernel RAM buffers that were used to temporarily hold pipe data. > For me personally this has not been a problem because I run kernels that > sanitize pipe buffers on last close of a pipe. > > 2) When hashing key material, sha512.c functions sha256_transform() and > sha512_transform() do not explicitly sanitize stack variables that may > contain data derived from last (65th) IV key material. In practice, > sensitive stack parts get overwritten by later stack usage of > losetup/mount programs. > > Other parts of losetup (and mount) always properly sanitize key material, > excluding 'kill -9' type events.
[source]
Also, the patch for sanitizing pipes is available here for 2.4 kernels [source].
[faq]
There are scenarios in which a loop-device is not auto-detached after unmounting. In such a case key material is still in RAM. That is worth mentioning, especially in light of the cold-boot attack.
If a mountpoint is set up like
mount /mountpoint
via an entry in /etc/fstab like
/dev/sda1 /mountpoint ext3 defaults,noauto,loop=/dev/loop1,encryption=AES128,gpgkey=key.gpg 0 0
then the loop-device is detached after unmounting, and key material in RAM is properly sanitized. The same is true for this approach:
echo "my very long passphrase" | losetup -p 0 -e AES128 -K key.gpg /dev/loop1 /dev/sda1
But the loop-device is not detached after unmounting if it is set up via
losetup -F /dev/loop1
as it is mentioned in loop-AES.README for running a filesystem check, f.e.
fsck /dev/loop1
When all is ok it is tempting to just mount the loop-device and continue work.
mount /dev/loop1 /mountpoint umount /mountpoint
If you run
losetup -a
the loop-device will still be listed. To detach the loop-device you need to explicitly run
losetup -d /dev/loop1
after unmounting.
[faq]
In short: That was sloppy work, don't worry.
In October 2006 there was an article published in the German "Linux Magazin" by Gutmann/Ney about crypted filesystems under linux, by now freely available here. Concerning loop-AES the authors solely dealt with loop-AES' compatibility mode (single-key mode!). The latest v3-multikey mode was not addressed at all, despite of its recommendation in loop-AES' readme for quite some time. Jari Ruusu's reply to the article can be found here, and is quoted in full length because of its importance (we all know how tricky mailinglist archives can be):
Jari Ruusu wrote: > Jens Lechtenboerger wrote: > > 3. The German Linux-Magazin 10/06 (http://www.linux-magazin.de) > > features an article by Peter Gutmann and Christian Ney, where > > they analyze different types of crypto filesystems. They > > recommend Truecrypt, dm-crypt is second, and they essentially > > warn against loop-aes: > > I tried to look for that Linux-Magazin article, but I didn't find it > on-line. Do you have a URL for it? Christian Ney was kind enough to send me english language draft of the article. It might not be exactly what was printed, but at least I have something to quote and respond to. Quote from the article: | Loop AES is available as a series of Linux kernel patches One patch for 2.6 kernels, one patch for 2.4 kernels, or alternatively, outside of kernel tree buildable kernel module that builds for all recent 2.6, 2.4, 2.2, and 2.0 kernels. Module version doesn't need any kernel patching. | the behaviour of the encryption can change radically depending on which | compile or runtime configuration options are chosen Compile time configuration options do not change on-disk format. Having optimized assembler implementations available for popular processors (x86 and amd64) and instruction set extensions (VIA padlock) are good things to have. Runtime configuration options are needed for compatibility with old on-disk formats. Killing compatibility with old on-disk formats is not responsible thing to do. | the code makes it quite difficult to pin down exactly what's going on, or | whether it's actually doing what it's supposed to be doing. The code is difficult to read, I agree. Short version of what it does, is here: http://mail.nl.linux.org/linux-crypto/2006-05/msg00049.html | LoopAES uses an unsalted hash of the password, applying a single iteration | of a hash function like SHA-256 or SHA-512 to obtain the disk key [snip] | makes it trivially vulnerable to a precomputed dictionary attack That obsolete code path is there for backward compatibility only. All examples in the README file and losetup man page use version 3 multi-key mode, and none of above applies to those examples. For many years, the recommended way has been to use gpg encrypted key files. gpg uses salted+iterated key setup, so precomputed dictionary attacks won't work. | Data is encrypted with AES in CBC mode kernel-2.6.15.diff, line 737, | with a confusing array of IV-processing options using either the raw | sector number or an MD5 hash as the IV. Raw sector number IV is there for backward compatibility only. | no function return codes are ever checked, so if anything goes wrong the | code continues with all-zero keys or unencrypted data. aes_set_key(), aes_encrypt(), and aes_decrypt() functions return void type. To check return value of void returning function would be a bug that compiler would refuse to compile. Those functions never return any error because they do not have any error situations that can make them return failed status. If above mentioned functions, or other kernel called driver hooks, are passed invalid pointers, then pointer dereferencing will cause kernel mode exception, and the process will cease executing with kernel "Oops", and the function never returns. As for RAM pre-allocations that are done at loop device set up time, all pointers are checked at least once at allocation time, but not thereafter. This claim of "continues with all-zero keys or unencrypted data" is completely bogus. My conclusion of this article's loop-AES section is that the technical review was done in hurry, and for some unknown reason seems to focus on bits that were obsoleted years ago. Maybe the reason of such mistake is because the source code does not have explicit comments about which sections of code are for handling obsolete compatibility bits.
[source]
[faq]
After having applied the kernel patch like
cd /path/to/kernelsources rm include/linux/loop.h drivers/block/loop.c patch -Np1 < /path/to/loop-AES-v3.4a/kernel-2.6.34.diff
just run "make menuconfig" to adapt the config options CONFIG_BLK_DEV_LOOP, BLK_DEV_LOOP_AES, BLK_DEV_LOOP_KEYSCRUB, and BLK_DEV_LOOP_PADLOCK, BLK_DEV_LOOP_INTELAES. You must set CONFIG_BLK_DEV_LOOP=y in order to have loop-AES support.
In case you have been using all features of the loop-AES module so far and want to use the same features with the loop module built-in, your .config should look like this:
grep LOOP .config CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_LOOP_AES=y CONFIG_BLK_DEV_LOOP_KEYSCRUB=y CONFIG_BLK_DEV_LOOP_PADLOCK=y CONFIG_BLK_DEV_LOOP_INTELAES=y
You can pass max_loop=<1-255> parameter to kernel on boot to adapt the number of available loop devices to your needs.
If you want to build twofish, serpent, and blowfish ciphers as well, use
cd /path/to/loop-AES/ make BUILD_LOOP=n EXTRA_CIPHERS=y
Again, only the AES code supports keyscrubbing, so adding KEYSCRUB=y parameter has no effect for the other ciphers.
Last but not least, be sure to adapt build-initrd.sh script:
USEMODULE=0
[source]
[faq]
In short, there is not. The only way to be safe is to prevent physical access to the machine in question.
There is a blog about the development of a general-purpose solution for mitigating cold-boot attacks on Full-Disk-Encryption solutions. (It seems to be deserted, and no means of contact are listed, sadly.)
On the other hand, the attack aims towards aquiring encryption keys. So why not give the attacker both what he is looking for anyway and slow him down at the same time? Concerning loop-AES, follow these guidelines:
The attacker does not know about the layout of your system, he is just looking for encryption keys in a memory image he has obtained through questionable methods. So by spamming the system RAM with encryption keys you let the attacker sort it all out and do not make it deliberately easy for him by just setting up the few encrypted loop devices you actually use.
While this procedure does not stop the attacker, it surely slows him down. Often this kind of attack is carried out with a relatively short time frame and this procedure just might buy you the time you need.
In case you know or have a feeling that your system has been subjected to the cold-boot attack (f.e. at US customs), ditch your current crypto setup and recreate it from scratch.
You can use this script to set up a number of encrypted loop-devices automatically on boot, different available ciphers are chosen somewhat randomly.
Usage: loopsetup.sh {loop# setup|destroy [verbose]}
#!/bin/bash
#
# written by markus reichelt, jan 2009
# ml@mareichelt.de, 0xCCEEF115
# public domain
#
# this script sets up loop# encrypted loop-devices
# to slow down the cold-boot attack
#
# start with first parameter to indicate starting
# loop device number till 255
# either use buildinitrd.sh script parameter
# LOOPMODPARAMS="max_loop=255"
# or use corresponding kernel parameter on boot
# in case you patched the kernel
#
# needs the other cipher modules loaded, namely
# loop_serpent, loop_twofish
#
# you may want to keep some spare loops for ordinary
# loop mounting of ISO images. adapt to your needs
#
# Usage: loopsetup.sh {loop# setup|destroy [verbose]}
#
# error codes:
# 1 - wrong usage
# 2 - adapt your config
# names the spare partition or file/device to set up the
# encrypted loop devices of this script.
# to be on the safe side, just use /dev/null
# ADAPT ACCORDINGLY!
#
#device=/dev/null
device=/dev/hda666
if [ "$device" = "/dev/hda666" ]; then
echo "Adapt your config!";
exit 2;
fi;
#PLEASE NOTE: you MAY have to adapt each occurance
# of loop$loop to loop/$loop depending on your
# system setup. should work out of the box tho
loop=$1
# array of ciphers used for a somewhat-randomly setup
# of encrypted loop devices
Ciphers="twofish256
serpent256
aes256
twofish128
twofish160
twofish192
serpent128
serpent192
aes192
aes128"
#blowfish left out deliberately, somehow that entry
#borks on me for whatever reason - YMMV
# read Ciphers into array variable ciphers
ciphers=($Ciphers)
# count how many ciphers we have in the array
number_ciphers=${#ciphers[*]}
# use ${ciphers[$((RANDOM%number_ciphers))]}
# to get a "random" cipher from the array
if [[ $# -lt 2 ]]; then
echo "Usage: $0 {loop# setup|destroy [verbose]}"
exit 1;
fi;
while [ $loop -lt 255 ]; do
case "$2" in
setup)
case "$3" in
verbose)
echo "Generating key for loop device #$loop and set it up"
esac;
# create 65 random keys and set up a loop-device with them, cipher is somewhat-randomly chosen
head -c 3705 /dev/urandom | uuencode -m - | head -n 66 | tail -n 65 \
| losetup -p 0 -e ${ciphers[$((RANDOM%number_ciphers))]} /dev/loop$loop $device
;;
destroy)
losetup -d /dev/loop$loop
;;
*)
echo "Usage: $0 {loop# setup|destroy [verbose]}"
exit 1
esac
let loop=loop+1
done
case "$3" in
verbose)
losetup -a
esac;
You can download this script here
Please note that this is just a crude proof-of-concept!
[source]
[faq]
In short, because of consistency reasons. See this quote:
Phil wrote: > I wish Jari would change the README to clarify the > possibility of building and installing loop-aes > without a kernel recompile by replacing an existing > loop driver module. It is not that simple. Rules: - Always compile kernel and all modules using same C compiler and tools. - Always compile kernel and all modules using same kernel sources. - Always compile kernel and all modules using same kernel configuration. All code that runs in kernel space must have same view of kernel data structures, and use same type generated code for locking and such. Deviating from above rules will often result in situation where that is no longer true. If kernel and modules are compiled on different boxes, then you run into these questions/problems: - Are you using same C compiler and tools as the party that compiled your kernel? Sometimes tools are upgraded on one box and not on other. - Are you using same kernel sources as the party that compiled your kernel? I can recall at least one distro that includes embargoed security fixes in their precompiled kernel binaries, but sources that they distribute do not include those fixes (to avoid disclosing those fixes). - Are you using same kernel configuration as the party that compiled your kernel? Distros ship different kernels compiled using different kernel configurations. Kernel sources and its configuration that you installed do not necessarily reflect the kernel binary that you installed. - Are your kernel sources in a state that can be used to compile kernel modules? Your distro may have "cleaned" your kernel sources by removing compile time generated files that are required to compile kernel modules. All this to save space.
[source]
[faq]
After you have installed dietlibc, the following should produce a static binary less than 2kbytes in size:
$ printf '#include <unistd.h>\nint main(){write(1,"hello\\n",6);}\n' >xxx.c
$ diet gcc -O2 -s xxx.c
$ ./a.out
hello
$
[source]
[faq]
Not much. If you have time on your hands, and still remember some details about your passphrase (like length, characters used, etc), there is hope. Folkert van Heusden has written a programme to recover a lost gpg passphrase. It's crude (slow) but it works and is your best shot right now. You can get it at http://www.vanheusden.com/nasty/ (gpgme library is needed).
In case his site is down, try here for nasty-0.6.tgz.
Please don't get false ideas about the timeframe, it will likely take days (weeks?), not minutes, at best.
[source]
[faq]
Since loop-AES uses the available ciphers in a block mode of operation, a corrupt block/sector does not cause havoc in the decryption of surrounding data. Please note that in this context, corrupt sector does not have the meaning of damaged medium sector. It means that the decryption of the sector in question does not yield the expected plaintext (because of flipped bits in the ciphertext on disk, unflushed write-cache during a hard system reset, premature unplugging of external devices, etc).
However, it does not matter how much of the encrypted sector has been corrupted as the decrypted data of the whole sector will appear scrambled.
The filesystem being used will react to a bad encrypted sector/block in the same way it would if the filesystem were not encrypted and the sector/block were bad. If it is a data block, then just that block will be bad; if it is a meta-data block, there may be further effects on the viability of the filesystem as a whole.
[thanks to John Fitzgerald]
[faq]
Therefore you should use tools that create redundant data that can be used later in case parts of the original data are lost or corrupted, like par2 or rar archives with recovery record.
The reason is backwards compatibility. Jari wanted to avoid breaking scripts that utilize some sort of send/expect tools. Therefore the patch to replace [P|p]assword with [P|p]assphrase in the sources was not accepted.
I try to make patches available for the latest loop-AES release and its predecessor, as time allows. In case you are interested, download the patches here:
The patches are signed with the key I also use for my slackbuilds, 0xCCEEF115 listed for reference in my GnuPG Key Signing Policy.
[source]
[faq]
Don't change in Linux Kernel Configuration "Processor type and features ---> High Memory Support" after building the loop module. This affects loop-AES v3.2g+
[source]
[faq]
Older implementations of dd in busybox do not honour the USR1 signal mentioned in coreutil's dd manpage, and the running dd process just quits when it receives a USR1 signal. This concerns usage patterns of dd as mentioned in sections 7.2, 7.3, 7.5 and 7.8 of loop-AES.README as well as section 3.4 of aespipe.README (adapted).
[source]
[faq]
This entry is being overhauled.
[source]
[faq]
Yes, since Version 3.3a the AES NI instructions are supported via INTELAES=y on make commandline. Alternatively, you can edit the Makefile so that line 58 looks like this:
INTELAES:=y
Also, if you are running a 32bit 2.4 kernel be sure to check loop-AES.README.
[source]
[faq]
The massconvert32.sh script also converts util-linux-ng. In case you want to add multilib support for your 64bit install after you installed the 64bit util-linux-ng package with loop-AES support, you need to get the 32bit package of util-linux-ng with loop-AES support instead of the official one.
[source]
[faq]
It is not if you are using GnuPG version 1.4.6 or later. Quoting loop-AES.README:
If you are using gpg version 1.4.6 or later you achieve same increased
password iteration effect without recompiling new gpg binary by setting this
option in your options file ~/.gnupg/gpg.conf
s2k-count 8388608
Or alternatively... You can use this gpg command line parameter:
--s2k-count 8388608
[source]
[faq]
There have been several efforts in the past to include loop-AES to mainline. Most recent efforts failed because of the paradox that there's no official loop-maintainer and hence efforts by OpenSuSE f.e. failed to get it included. Upstream policy is followed, by f.e. util-linux-ng, meaning that because mainline kernel does not include loop-AES, there's no loop-AES support in util-linux-ng. The only person who could bring life to this deadlock situation is Linus himself (either appointing a loop maintainer or getting foo done himself). Chances are slim of that actually happening.
[source]
[faq]
No there isn't. When asked about it Jari declined to port it. And I don't know of any howtos on how to best port linux foo to OSX (mail me interesting links).
However, if you feel inclined to pursue that challenge, it basically boils down to this: a) get the loop module replaced & the loop-AES version to complile b) get util-linux(-ng) patches with loop-AES support to compile.
[source]
[faq]
First of all, this should not happen. If you experience occasional freezes tho (especially when writing large amounts of data to the crypto partition), choose the memory allocator SLAB instead of SLUB. These days SLUB seems to be the default.
In the Linux Kernel Configuration (make menuconfig), in General Setup, go to
Choose SLAB allocator (SLUB (Unqueued Allocator)) --->
and select SLAB so that the entry reads
Choose SLAB allocator (SLAB) --->
Then exit/save and recompile the kernel.
[source]
[faq]
Copyright © 2007 - 2010 markus reichelt.
If you want to contact me, send an email in plain text only to the address listed below; encrypted email is preferred. Have a look at my GnuPG Key Signing Policy.
Encrypted and anonymous message box available at https://privacybox.de/mareichelt.msg, or as Tor Hidden Service in case you prefer such a method of contact. Be advised that the subject will not be encrypted, only the text message itself. Also, in case you want a reply, please provide secure means of contact.
[top]
[top]
[ return to publications page ]
| markus reichelt <markus.reichelt@gmx.net>Last modified: 2010-08-14 | angstklausel - site policy - imprint | | | | | |