Tag Info

New answers tagged

2

It's not an error, so you shouldn't try to make it go away. The scripts in your initramfs are opportunistically checking to see if they can activate the LVM VG that contains your root device before they bother asking for a passphrase to decrypt any encrypted devices. In the case that your root device is not encrypted, this will work, and the system will ...


3

Yes (for your own bootloader / initramfs) and No (for a thief who tries to decrypt it from a Live CD and thus circumvents your trap). So the question is, which situation are you trying to cover here... From a security standpoint it's not a good idea since it doesn't work and the password should be impossible to bruteforce anyhow. Also there is a high risk ...


2

A quick look around my Debian "wheezy" system suggests that it would be perfectly possible to insert such a boobytrap in the function do_luks, located in the shell script library /lib/cryptsetup/cryptdisks.functions, which is called from /etc/init.d/cryptdisks-early. After changing the code it would be necessary to run update-initramfs to ensure that the ...


0

Screw grub. It's probably some complexity it introduces that leads you to believe this is a difficult problem to solve. If your computer is less than 5 years old or so, then you're probably booting from a UEFI firmware, in which case your Debian-built linux kernel is already a bootloader. Partition the disk: printf %c\\n o y n 1 '' '' ef00 w y | gdisk ...


1

For starters, you could partition and format and mount the USB stick copy all files from your old /boot to the USB stick change your /etc/fstab to make the USB stick filesystem the new /boot umount /boot, mount /boot to make it official install a bootloader on the stick (grub-install /dev/sdx or whatever) reboot and see if it works As for reclaiming the ...


1

The answer (as I now know): concurrency. In short: My sequential write, either using dd or when copying a file (like... in daily use), becomes a pseudo-random write (bad) because four threads are working concurrently on writing the encrypted data to the block device after concurrent encryption (good). Mitigation (for "older" kernels) The negative effect ...


4

The two obvious candidates would be ZFS and Btrfs, but as far as I know, they don't do this. Btrfs currently has no crypto at all (for encryption, you're supposed to use LUKS, which provides encryption and optionally block-level integrity but not global integrity). ZFS has an integrity mode where it uses a tree of cryptographic hashes to ensure that the ...


3

First: run dmsetup table --showkeys. Save the output of that somewhere safe—that big long hex string it shows is the actual encryption key (master key) used to secure your data. LUKS works by (simplification here) encrypting that key with your passphrase(s), so keep in mind that compromise of that key means game over—a passphrase change won't help. You have ...


2

Does the speed of USB-device matter? It matters for the boot process itself. It has to load the bootloader, kernel and initramfs from USB, which can be several MB altogether, so it can make a difference of a few seconds. Does the system contiously use the bootloader to decrypt No. Usually you can pull the USB device out as soon as the first kernel ...



Top 50 recent answers are included