Debian based distributions:
Debian and Ubuntu ship a password caching script decrypt_keyctl with cryptsetup package.
decrypt_keyctl script provides the same password to multiple encrypted LUKS targets, saving you from typing it multiple times. It can be enabled in crypttab with keyscript=decrypt_keyctl option. The same password is used for targets which ...
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 ...
You have to pay attention to UUIDs . For instance, this is my configuration:
# lsblk -o name,uuid,mountpoint
│ └─sda2_crypt (dm-0) P1kvJI-5iqv-s9gJ-8V2H-2EEO-q4aK-sx4aDi
│ ├─debian_crypt-swap (dm-1) 3f9f24d7-86d1-4e21-93e9-f3c181d05cf0 [SWAP]
│ ├─debian_crypt-tmp (dm-2) ...
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 with ...
It's about online resize.
For example if you use LVM, create a LV of 1G size, and put LUKS on that, it's like this:
# lvcreate -L1G -n test VG
# cryptsetup luksFormat /dev/mapper/VG-test
# cryptsetup luksOpen /dev/mapper/VG-test lukstest
# blockdev --getsize64 /dev/mapper/VG-test
# blockdev --getsize64 /dev/mapper/lukstest
So the ...
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 ...
If the decrypted volume is /dev/mapper/crypto then you can get the information with
dmsetup table crypto
0 104853504 crypt aes-cbc-essiv:sha256 000[...]000 0 254:2 4096
If the encrypted volume is /dev/storage2/crypto then you get the information with
cryptsetup luksDump /dev/storage2/crypto
LUKS header information for /dev/storage2/crypto
Your logic is not incorrect. But it is only valid if some conditions are satisfied.
The TRIM command, as specified in the ATA command set, may or may not zero the sectors it is issued against.
Actually, the standard focuses on what data has to be returned after TRIM has been issued1:
The follow behaviors are specified by this standard for sectors that ...
It appears that dmsetup computes its alignment from the optimal I/O size, without bothering to check that that is actually a multiple of the physical block size. As mentioned in the false warning question, this optimal I/O size makes sense due to USB constraints.
So the solution is simple: use --align-payload to override the detected value. A value of 8 ...
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 ...
You could make use of the --batch-mode, -q option of cryptsetup to skip the question.
$ cryptsetup -q luksFormat /dev/sdb
This option also disables password verification, so one should use it with care or in an automated environment
cryptsetup expects the sector size to be 512, but in your case it seems to be 4096, since that is what truecrypt does for devices with physical/logical sector size of 4096. This information is stored in the TrueCrypt header, you can also see it with cryptsetup tcryptDump.
The Linux version of truecrypt mounts such containers fine like so:
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 ...
Depends on what the init script that asks the password of you is doing with it.
If it's systemd, it might just be a feature. systemd-ask-password comes with a cache functionality that might be responsible.
If passed, accept cached passwords, i.e. passwords ...
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 ...
I had the same problem! Turns out systemd was lacking such an option, so I have implemented it myself. It is included in systemd 232 or later. (You also need cryptsetup 1.67 or newer for the actual cryptography support, but it sounds like you have that since the manual mount works.)
The new crypttab option is tcrypt-veracrypt; it implies tcrypt so you ...
You can store the actual passphrase for cryptsetup (possibly a very long and complicated string) in a file encrypted by GnuPG (or any other tool) with another passphrese you can remember.
First encrypt a passphrase string with gpg to get encrypted keyfile:
# echo 'long-long-passphrase-for-cryptsetup' | gpg -q -c --cipher-algo AES256 -o keyfile
KDF speed is important, but contrary to your belief, it should be SLOW.
With LUKS, your encrypted drive contains a header with an encrypted master key that is used to encrypt your device. This master key gets decrypted with one of the keys in your key slots when you boot/open the device (try cryptsetup luksDump /dev/sdx to see information contained in the ...
fdisk is being a bit stupid here: when displaying device names for the partitions, it just takes the name of the whole-disk device given to it, and appends the partition number (prefixed with p if the last character of the whole-disk device name is also a number). It does this without checking if a device by that name actually exists or not.
In other words, ...
That might be a question for security.stackexchange.com but I'm sure it has been asked before somewhere.
Basically, it masks "free space", so no one can tell how much data you have on your encrypted partition and where it is stored. How important that is to you is your affair.
If the disk was in use before that, it also gets rid of old, unencrypted data. ...
Your kernel lacks support for aes-cbc-essiv:sha256. “Error allocating crypto tfm” refers to the kernel's cryptographic subsystem: some necessary cryptographic data structure couldn't be initialized. Your support for cryptographic algorithms comes in modules, and you have a module for the AES algorithm and a module for the SHA-256 algorithm, but no module for ...
LUKS doesn't “auto-unlock” a volume. The volume becomes accessible when you open it, which requires the key. The volume remains inaccessible when you close it; you can only close it when it is not in use, so you must close any open file and unmount the filesystem.
cryptsetup luksRemoveKey would remove the key from the volume, which would make it unreadable. ...
You can use the keyscript option in your crypttab instead (man crypttab). Just create a script that echos your passphrase and set it as the keyscript argument, then regenerate your ramfs. You don't need any hooks, and you don't need to put the script in /boot/.
vg1-root_crypt UUID=94a3b301-123-12-a3-ea0403 none luks,keyscript=/etc/echo-root-luks-pass
It seems that cryptsetup requires the LUKS header to be either regular file or device. If you need to provide the LUKS header as an output from a process/stream, you can easily circumvent the restriction by sending it to /dev/ram
cat LUKS-HEADER > /dev/ram0
(provided that your kernel supports ramdisk)
Then you can then simply use your cryptsetup ...
For example, consider the server I work on. The hard disk has a small /boot partition, /dev/sda1, which is by necessity not encrypted, and a large encrypted partition, /dev/sda2, which hosts a LUKS container, which, when opened by cryptsetup automatically at boot after entering the passphrase, appears as /dev/mapper/Serverax. In the container there is a LVM ...
I did everything like in the guide except I did not generate a new random key and added it to the harddisk but used the passphrase I always used and wrote that into a file.
Passphrase in file works fine, but it must not have newline at the end.
Verify that it works with --key-file option:
cryptsetup open --verbose --key-file yourfile --test-passphrase /...
To really ignore the message and do not skip the partition, you need (at least) comment out/delete the return 1 in /usr/share/initramfs-tools/hooks/cryptroot after the line where the error message
is written (around line 274 - depening on the used cryptsetup version). Beware that this file is by default managed by the package manager,
and therefore is ...