Hot answers tagged

25

Yes, you can do this by accessing the master key while the volume is decrypted. The quick and dirty to add a new passphrase: device=/dev/sda5 volume_name=foo cryptsetup luksAddKey $device --master-key-file <(dmsetup table --showkeys $volume_name | awk '{ print $5 }' | xxd -r -p) device and volume_name should be set appropriately. volume_name is the ...


9

Backup Reformat Restore cryptsetup luksRemoveKey would only remove an encryption key if you had more than one. The encryption would still be there. The Fedora Installation_Guide Section C.5.3 explains how luksRemoveKey works. That it's "impossible" to remove the encryption while keeping the contents is just an educated guess. I base that on two things: ...


9

In most scenarios, one of the following three schemes works well. You only want to encrypt a few particularly confidential files. Use encfs: mkdir ~/.encrypted.d ~/encrypted encfs ~/.encrypted.d ~/encrypted editor ~/encrypted/confidential-file Pros: no overhead to access non-confidential files; you can have different hierarchies with different passwords;...


8

After backing up (step 1) and unmounting (between 2 and 3), run fsck to ensure that the filesystem is healthy: e2fsck -f /dev/mapper/ExistingExt4 Other than that, the steps are OK. what should I choose for $SECTORS? Is this step even necessary? This step is necessary, otherwise the partition would still show up at the old side. This is confirmed ...


7

I've implemented support for storing your LUKS key in TPM NVRAM, and RHEL6 happens to be the one platform where all features are fully tested, see this post: [1] http://security.stackexchange.com/a/24660/16522


7

Warning, wall of text incoming. It's as well formatted as I could make it. If we're going to answer this, we're going to answer the whole thing. I'm not doing another answer on this, so here goes: Let's pretend you know absolutely nothing, and I'm feeding you keystrokes. This tells you everything you need to know to do this WHOLE thing, with a little ...


7

cryptsetup luksDump /dev/fedora/01 shows the LVM logical volume to be a LUKS encrypted volume. The output of pvs or pvdisplay would show the partition /dev/sda3 to be a physical volume. Thus you have LUKS over LVM. At a lower level, you have LVM over PC partition. The output of lsblk confirms this: sda is a disk, sda3 is a partition (which contains an LVM ...


7

For the prompt to work, you need to add -t. ssh -t root@host cryptsetup luksOpen /dev/thing luksthing (It also works if you just type out your password when it's "stuck" waiting for input, but it will echo in your local terminal.) Alternatively, piping the passphrase works well enough: echo -n 'password' | ssh root@host cryptsetup luksOpen /dev/thing ...


7

dmsetup is useful for anything device mapper related. For Example: [root@localhost]~# dmsetup ls --target crypt luks-90dc732d-e183-4948-951e-c32f3f11b305 (253, 0) [root@localhost]~#


6

In fact, modifying mount is possible, as I learned from the existence of mount.ntfs-3g. I'm doing only guesswork, but I suspect mount -t sometype results in a call to mount.sometype $DEV $MOUNTPOINT $OPTIONS, feel free to correct me here or quote some actual documentation. Especially the option -o loop is already treated so there's no need for lopsetup ...


6

Your approach looks good. Some remarks though: If you want to encrypt rootfs, you'll need to use initrd (to have some minimal unencrypted system that will process the encrypted partitions). If the USB device is removable, both initrd and kernel can be stored on the USB to heighten tamper resistance (supposing you make sure the USB won't get into ...


6

Many Linux distributions use an in-memory filesystem as a temporary root filesystem when booting. There are two forms of such in-memory filesystems: initrd, the traditional form, which is a RAM drive, and initramfs, the modern form, which is a filesystem filled by data from an archive. The job of the programs on the initrd (or initramfs, the difference is ...


5

If you do not overwrite the previous contents of the disk, any old information will remain in a trivially (software-only) readable form until it happens to be overwritten, which may be a very long time (bordering on forever). If you do overwrite the previous contents of the disk with zeroes before creating the LUKS data structures on-disk, you have largely ...


5

What you call “standard” partitions are IBM PC partitions. The point of using them is to be compatible with other operating systems that like or even require IBM PC partitions. Inside a Linux software RAID volume, or inside a LUKS encrypted volume, only Linux cares. So you might as well use Linux's native partitioning system, i.e. LVM, which is a lot more ...


5

This uuid "EFc551-(...)" probably is your 2TB disk (namely encrypted PV on it). You need to tell somehow your initramfs about this second PV. Probably update-initramfs will do it, something like (from knoppix): (assuming you've mounted your disk in /mnt/disk) cp -a /dev/* /mnt/disk/dev/ chroot /mnt/disk mount /proc mount /sys update-initramfs -u -...


5

If all you want to change is the hash, there is no need to re-encrypt. You still have to build a new LUKS header though. Same cipher, same master key, same offset, different hash. You can try this for yourself. First we set up a LUKS device with standard settings and lousy iter counts: # truncate -s 8M /dev/shm/foobar # cryptsetup --iter-time=42 luksFormat ...


5

Parted prompts and goes into an interactive mode when you do not provide enough information to create the partition with the command. The following will create a partition that spans the entire disk and will not prompt for filesystem type: mkpart primary 1 -1


5

The easiest way to solve this is to add a derived key from the first partition to to the second disk by running: /lib/cryptsetup/scripts/decrypt_derived sda1_crypt > new_key_file cryptsetup luksAddKey /dev/sdb1 new_key_file # prompts for an existing key shred -u new_key_file # remove the key file Then replace the sdb1_crypt line ...


5

You have to remember there are two layers of abstraction involved here. You don't "mount" an encrypted disk. You open the encrypted disk with cryptsetup (if you have the correct password). This will create a mapping of the de-crypted partition at /dev/mapper/foo. Then you can mount /dev/mapper/foo to your desired mountpoint (such as /disk2). These are two ...


4

Did you update on your 2TB hdd the /etc/fstab to point to the correct UUID of the encrypt volume? In case you don't know what is the UUID of the encrypt volume you can check by issuing the cmd: cryptsetup -v status /dev/ After you need to update your /etc/fstab and the grub configuration to point to the correct UUID. This should solve your question ...


4

You can use /lib/cryptsetup/scripts/decrypt_derived in your crypttab to automatically use the key from one disk for another. The decrypt_derived script is part of Debian's cryptsetup package. Small example to add the key from sda6crypt to sda5: /lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile cryptsetup luksAddKey /dev/sda5 /path/...


4

You are unlikely to be happy with the huge latencies introduced by LUKS on linear media. A better idea is to pipe the output of tar through OpenSSL, encrypting it with a streaming cipher, before sending it to the tape device.


4

LUKS sometimes gives the No key available error message when the cipher isn't supported. Which cipher did you use? For supported ciphers, check /proc/crypto. Also, passphrase may depend on keyboard layout and (if it has non-ascii characters) charset encoding. The keyboard layout problem can be worked around by adding another passphrase that would match the ...


4

It doesn't work because the /etc/crypttab line is missing the option keyword luks. Changing the line to this resolved the issue: luks-01a2e5d8-9211-40ce-b160-d3f973d1a155 UUID=01a2e5d8-9211-40ce-b160-d3f973d1a155 /etc/luks-keys/luks-01a2e5d8-9211-40ce-b160-d3f973d1a155 luks,nofail This is due to the fact that cryptdisks_start uses the options to determine ...


4

The LUKS format has multiple key slots, each one may contain the encrypted master key that is used for data encryption. This master key is encrypted using another key which is derived from your passphrase. Using plain hash_function(passphrase) to generate a key would be dumb as hashes such as sha1 can be calculated fast (SHA-1 is an example of a MAC ...


4

1a - it really doesn't matter all that much. which ever hash you use for the key derivation function, LUKS makes sure it will be computationally expensive. It will simply loop it until 1 second real time has passed. 1b - the key derivation method has no influence on performance. the cipher itself does. cryptsetup benchmark shows you as much. 2 - AES is the ...


4

Your layering is suboptimal because putting the raid 5 on top of the encryption means that you increase the number of encrypt/decrypt operations by 25 % - since 4 * 4 TB are encrypted. When putting the encryption on top of the raid 5 only 3 * 4 TB are encrypted. The reasoning behind that is: you don't have to encrypt parity data (which takes up 4 TB in ...


4

No, LUKS only supports PBKDF2 as the key derivation function. PBKDF2 is built on a cryptographic hash function, and you can select the hash function with --hash, as well as the iteration count via --iter-time. All supported hash functions are equally secure for this use case; a higher iteration count makes the job proportionally harder for the attacker but ...


4

It's very odd to have a LUKS inside a plain crypt. Why encrypt twice? Once your filesystems are mounted, lsblk will show you what's what. NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 59.6G 0 disk └─sda1 8:1 0 59.6G 0 part └─md0 9:0 0 ...


4

The master key bears no relationship to any of the possible passwords (recall that with LUKS you can have multiple passwords to unlock a single master key). Per the cryptsetup FAQ: LUKS PASSPHRASE IS NOT THE MASTER KEY: The LUKS passphrase is not used in deriving the master key. It is used in decrypting a master key that is randomly selected on header ...



Only top voted, non community-wiki answers of a minimum length are eligible