Assuming that I want to encrypt/decrypt a hard drive corresponding to /dev/sdX, the following is the procedure I have for doing so: **Encryption:** 1. Write the hard drive's data into a file (e.g. ./tmp), using the command dd if=/dev/sdX of=./tmp 2. Encrypt the tmp file using any secure file encryption algorithm 3. Write the encrypted tmp.enc into the hard drive (dd if=./tmp.enc of=/dev/sdX) **Decryption:** 1. Write the hard drive's data into a file (e.g. ./tmp), using the command dd if=/dev/sdX of=./tmp.enc 2. Decrypt the tmp.enc file 3. Write the decrypted tmp into the hard drive (dd if=./tmp of=/dev/sdX) Does the following method necessarily work?

I'm looking for a clear tutorial on how to do this but I'm encountering insufficient information everywhere. Namely, I have a laptop with the following disk configuration: Drive one has Fedora 38 installed and the drive is encrypted. However, I have a second SSD, independent of the one on which Fedora 38 is installed, and I would like to encrypt it with LUKS as well. I have searched and read but I am lost. https://docs.fedoraproject.org/en-US/quick-docs/encrypting-drives-using-LUKS/#_remove_a_passphrase_or_key_from_a_device reading the official Fedora guide to LUKS encryption, I can not grasp the idea of how to implement this to the second SSD independent drive so that if, for example, I need to reinstall Fedora or another system on the drive on which the operating system is currently, I do not fear losing access to the second drive encrypted. 1) How to correctly implement the above (or other) guide to have the second SSD encrypted? 2) What steps would have to be considered in such a solution to have access to this drive in case of reinstallation of the system or blowing out the drive with the operating system? (I mean here a copy of the keys, etc. ?) 3) I tried this tutorial from point 4 and unfortunately ended up somewhere with my mistake and after rebooting the system I had to enter twice the password to the encrypted drive with OS and to the other SSD drive but unfortunately after entering both passwords correctly, I received a message about the need to log in as root to repair the system. 4) Is it possible to implement a solution so that it only asks for the password to the encrypted partition with OS, and to the second drive only from within Fedora ? I would be grateful if someone would try to explain it to me, I have searched really many places from Fedora, here, Youtube as well as other articles but I am probably too stupid to understand it.

We have two servers. Application sever A and NFS file server B. Server B is shared among multiple various applications and it's generic NFS storage host that we don't have access to and it's corporate shared storage. Application server A processes very sensitive data and then stores them on NFS shared with everyone. Since it's far from perfect situation, we need to store data from Application server A on NFS in encrypted form so that it can't be read/processed even if one would have full access to NFS server B. We've set this up with gocryptfs but we're suffering from severe performance issues so this time we decided to give ecryptfs a go. I tried to crawl through ecryptfs and encfs tutorials and docs but all of them seem to be focused on automounting filesystem at login. For us there will be no login. It's autonomous machine that is supposed to automatically boot after power failure and automatically mount encrypted volume at boot time, without human intervention. We need to provide passphrase via file stored on Application server A disk. How can I do that? We tried to use fstab with: /mnt/nfs_encrypted /mnt/nfs ecryptfs nofail,rw,relatime,ecryptfs_sig=5d6b2xxxxxxx35,ecryptfs_cipher=aes,ecryptfs_key_bytes=16,ecryptfs_unlink_sigs 0 0 but it fails to mount at boot time since keyring is empty after each reboot.

Key load error: Failed to open key material file: Input/Output Error.
Command: mount -o zfsutil -t zfs rpool/ROOT/ubuntu_uy913 /root/.
Message: zfs_mount_at() failed: encryption key not loaded.
zfs_mount_at() failed: encryption key not loaded.
Mounting rpool/ROOT/ubuntu_uy913 on /root/ failed: Permission denied.
Error: 2.

Failed to mount rpool/ROOT/ubuntu_uy913 on /root/.
Please manually mount the filesystem and exit.

BusyBox v1.30.1 (Ubuntu 1:1.30.1-7ubuntu2) built-in shell (ash).
Enter 'help' for a list of built-in commands.

(initramfs):

Hello everyone, after turning off my machine, when I tried to turn it back on and entered my passphrase, this is what I encountered. Now I'm quite upset because I'm not sure what the issues are.

I've tried everything I know until I'm exhausted. Please, if you can help me, I need to access my project stored on my hard drive. The command I used:

sudo zfs load-key rpool/ROOT/ubuntu_uy913x

And the error message I received:

Key load error: Keys must be loaded for encryption root of 'rpool/ROOT/ubuntu_uy913x' (rpool).

I use full disk encryption which uses an LVM. It uses like this in lsblk: NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 465,8G 0 disk ├─sda1 8:1 0 200M 0 part /boot/efi ├─sda2 8:2 0 500M 0 part /boot └─sda3 8:3 0 465,1G 0 part └─luks-3f530000-b2c3-4ba3-9e85-1a96494cc25d 253:0 0 465,1G 0 crypt ├─fedora_martin--friese-root 253:1 0 50G 0 lvm / ├─fedora_martin--friese-swap 253:2 0 7,8G 0 lvm [SWAP] └─fedora_martin--friese-home 253:3 0 407,3G 0 lvm /home The same setup I had with Ubuntu for several non-LTE releases as well. On the first installation, it worked fine on both Ubuntu (say 14.10) and now Fedora 22. When I upgraded the Ubuntu I occasionally had with issue (around 15.04 I'd say). On Fedora 22 it was not a problem until the upgrade to Fedora 23. Now I have the A stop job is running errors. In total there a couple errors that cycle through (except that the time is increasing): - (1 of 8) A stop job is running for LVM PV NVB… on /dev/dm-0 (20 s / 1min 30s) - (2 of 8) A stop job is running for LVM PV NVB… on /dev/dm-0 (20 s / 1min 30s) - (3 of 8) A stop job is running for LVM PV NVB… on /dev/dm-0 (20 s / 1min 30s) - (4 of 8) A stop job is running for LVM PV NVB… on /dev/dm-0 (20 s / 1min 30s) - (5 of 8) A stop job is running for LVM PV NVB… on /dev/dm-0 (20 s / 1min 30s) - More of them. I did not get to make pictures of all of them. But with the pattern I assume that number 6 and 7 are the same type. - (8 of 8) A stop job is running for LVM PV NVB… on /dev/dm-0 (20 s / no limit) The last one has no time limit, which is interesting. After the timeout is over, it dumps a couple more messages and leaves me with the following:  From the last line it seems that it cannot properly unmount and luksClose the encrypted volumes. My setup is just plain Awesome WM (and has been that on Fedora 22 as well). I usually log off in Awesome wM and then click the poweroff button in SDDM, the display manager. That way I do not have to enter systemctl poweroff and I have the hope that all my user programs are closed before the shutdown starts. What can I do to find the thing that blocks the proper closing of the LVM crypto devices? ---- ## Update 2016-01-05 I have uploaded a [log from the whole shutdown](http://chaos.stw-bonn.de/users/mu/uploads/2016-01-05/boot2.log) . In the end it does say that it was not able to close the device as it was busy but I do not see why it has been busy. What is the cause for this?

I am running Ubuntu server 24+ and desktop and also Kubuntu 24+ and I installed all of them using the encryption option. Now, every time I turn on one of those machines I need to personally enter the encryption key at the needed computer and therefore I need to ask how to remotely enter an encryption key to boot an encrypted Ubuntu. I read: https://unix.stackexchange.com/questions/5017/ssh-to-decrypt-encrypted-lvm-during-headless-server-boot but it seems to be out of date. Any suggestions?

A friend of mine had someone install Kali on his Lenovo thinkpad. He provided the username and password which I believe is for logging into the system. The only issue is that I think he encrypted the drive so when it boots up we get an message that says “Please unlock disk nve0n1p3_crypt” Tried to even go into the recovery modes but all seem to be locked as well. The password he provided is not working and he doesn’t recall if it is the same one. How do we go about unlocking or resetting the whole thing?

I read that the f2fs format is good for SSD storage so I formatted one of my drives with it. I also read in some kernel notes that encryption was added for it but there's no documentation to speak of. I typically prefer whole disk encryption. I'm not sure if that's possible for f2fs. I'm wondering if anyone knows any steps in which I might be able to encrypt an f2fs drive. I know it's done on Android for their full drive encryption (I'm running Ubuntu). Is LUKS filesystem agnostic? I don't think so. Any encryption would be good. No docs == no good. Here's a reference of kernel updates: http://lkml.iu.edu/hypermail/linux/kernel/1506.3/00598.html

My situation is a bit unique: The scenario ~ I have successfully encrypted my root partition and boot partitions. My boot partition lies on my usb along with the /boot/efi on a separate unencrypted partition on the usb. I use grub and my system works fine as is. But, I would love to skip the boot password (since i will keep my usb secure) and really just encrypted the /boot partition as a just in case measure. So, I have a keyfile already linked to the /boot partition and its well hidden and disguised so nobody can assume its there on the /boot/efi unencrypted partition within the usb. With all that said, how can i get grub to use this keyfile to decrypt the boot partition at boot? (I saw a tutorial that demonstrates something similar to this om the arch wiki dm-crypt page, but its methods didn't work because they could be outdated?) Or is there a better method of securing my boot usb to be suggested? I even tried to just use veracrypt hidden volumes on linux with little success.

i recently bought a new laptop an HP Essentials Business Laptop seen on Amazon as: HP Essential Business Laptop, 17.3" FHD Display, Intel Core i5-1334U, 32GB RAM, 1TB PCIe M.2 SSD, Wi-Fi 6, Webcam, Backlit Keyboard, Windows 11 Pro, Silver I downloaded linuxmint-22.1-cinnamon-64bit and flashed it to a USB to install to the laptop now on my new laptop, i have a 1tb SSD drive, and i would like to partition it into two encrypted 500gb drives, one for my system one for my files why? a few reasons 1: i would like to be able to reformat my system for security purposes and not lose all my files 2: i would like to not lose all my files if my system were to have a problem and get corrupted and i need to reformat for that reason 3: i would like to be able to reformat and distro hop when ever i want and not lose my files with that being said, how do i do this? i am able to boot up into Linux mint with my new laptop, i go to select something else but then it gives me this weird partition table that i have no clue about and I'm lost any help would be appreciated, thank you

I am attempting to install Kali on a laptop, which should normally be straightforward. However, on this particular device, the Kali installer errors upon writing the partition changes to disk for some reason. I was previously able to get around this issue by partitioning the drive manually via fdisk. Kali was running great. However, I was lacking disk encryption. So, I wiped the drive and set out to partition and configure Kali manually, with LUKS encryption. I found an article for this which I was able to follow with only a few deviations https://devconnected.com/how-to-encrypt-root-filesystem-on-linux/ The partition scheme I ended up with is as follows Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors Disk model: WDC WD5000LPVX-7 Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disklabel type: gpt Disk identifier: C6EB1185-05CF-4E8D-ABAC-1376C75628F8 Device Start End Sectors Size Type /dev/sda1 2048 1953791 1951744 953M Linux filesystem /dev/sda2 1953792 3907583 1953792 954M EFI System /dev/sda3 3907584 976773119 972865536 463.9G Linux filesystem With sda1 as /boot (needed due to BIOS legacy boot things), sda2 as /boot/efi and sda3 as my root encrypted filesystem. This scheme worked for an unencrypted Kali install, so all I needed was to setup LUKS. Using cryptsetup as detailed in the article I have the following for sda $ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 465.8G 0 disk ├─sda1 8:1 0 953M 0 part ├─sda2 8:2 0 954M 0 part └─sda3 8:3 0 463.9G 0 part └─crypto 254:0 0 463.9G 0 crypt ├─cryptVG-swap 254:1 0 2G 0 lvm └─cryptVG-root 254:2 0 461.9G 0 lvm I am running Kali on a live USB to setup my laptop hard drive, and the article details moving an existing OS install over to an encrypted install. I can't rsync the live medium files and have the OS work like an actual (not live) install, so I simply used Kali's installer to write the install to a USB as if it were a hard drive (unsure why the installer writes partitions fine to a USB yet not my disk, but w/e). I was then able to mount both and rsync the USB's root file system to my encrypted disk. This seemed to work like a charm. I was also able to reinstall grub as detailed without major issues, after a small change in that section. Basically I used --rbind when mounting /dev before chrooting to avoid a sudo error, and I also needed to mount/bind proc before chrooting too. After chrooting successfully I still got an error stating that the hostname "kali" couldn't be resolved anytime I ran sudo, but it didn't seem to impact the commands I was running so I ignored it. My grub setup ended up as follows: UUIDs $ lsblk -f NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS sda ├─sda1 │ vfat FAT32 9080-831D ├─sda2 │ vfat FAT32 345D-5BB8 └─sda3 crypto 2 f0b2bee7-9566-4178-9a3a-6ffee87482df └─crypto LVM2_m LVM2 6t1L5r-GdTD-Fda4-A3D7-OjMI-DiI9-mKM76J ├─cryptVG-swap │ swap 1 9d7471b5-cd00-477b-a599-48517194122c └─cryptVG-root ext4 1.0 740ca216-99a9-46ee-a2c2-fa2dbde2ccb7 417.1G 3% /mnt /etc/fstab $ cat /mnt/etc/fstab # # root UUID=740ca216-99a9-46ee-a2c2-fa2dbde2ccb7 / ext4 errors=remount-ro 0 1 # efi UUID=345D-5BB8 /boot/efi vfat umask=0077 0 1 # swap UUID=9d7471b5-cd00-477b-a599-48517194122c none swap sw 0 0 /etc/crypttab $ cat /mnt/etc/crypttab # crypt UUID=f0b2bee7-9566-4178-9a3a-6ffee87482df none luks Based on these configs it *seems* like I should be able to boot into the OS fine. I have the UUIDs correct as far as I can tell and I have grub stage 1 installed fine because it prompts me for a password to unlock the device. However, while I am able to unlock /dev/sda3 with my password using cryptsetup luksOpen /dev/sda3 crypto, using this same password on the boot screen gives me an incorrect password error. Upon booting into sda I see Enter passphrase for hd0,gpt3 (f0b2bee7-9566-4178-9a3a-6ffee87482df): And upon entering the correct password it immediately prints error: Invalid passphrase error: no such cryptodisk found error: disk `lvmid/kJKtcZ-eQPE-zpEE-r5hz-MWlz-WdzV-hg2lMF/GAVDs1-caOS-pBlM-bQsb-MDyN-2LdM-nyQveG' not found grub rescue> **Why can grub not unlock my LUKS drive while cryptsetup can? How can I fix grub so it can?** *I understand this is technically an XY problem but I have tried solving X (Kali installer failure) without success as it seems no one else has my issue, and I am so close to solving Y at this point I don't think it matters. Plus I want to learn more about grub.* Edit: luksDump info $ sudo cryptsetup luksDump /dev/sda3 LUKS header information Version: 2 Epoch: 3 Metadata area: 16384 [bytes] Keyslots area: 16744448 [bytes] UUID: f0b2bee7-9566-4178-9a3a-6ffee87482df Label: (no label) Subsystem: (no subsystem) Flags: (no flags) Data segments: 0: crypt offset: 16777216 [bytes] length: (whole device) cipher: aes-xts-plain64 sector: 4096 [bytes] Keyslots: 0: luks2 Key: 512 bits Priority: normal Cipher: aes-xts-plain64 Cipher key: 512 bits PBKDF: argon2id Time cost: 4 Memory: 1048576 Threads: 4 Salt: 73 ... 12 AF stripes: 4000 AF hash: sha256 Area offset:32768 [bytes] Area length:258048 [bytes] Digest ID: 0 Tokens: Digests: 0: pbkdf2 Hash: sha256 Iterations: 77101 Salt: c2 ... 80 Digest: c7 ... 43

In Linux in Bash i run a script with some cryptsetup calls like --luks2-metadata-size=16k --luks2-keyslots-size=256k .... luksFormat .... that brings Warning outputs. I know and understand, but i will these Warnings not see at the screen. How can i suppress them, but show error messages?

That is, when a device-mapping is created manually with the dm-crypt target, is the resulting device smaller than the backing device? What is the missing space used for? Will the answer change depending on which crypto mode/algorithm is used?

i will create some write once read many files. i need only one key for open the file and for me, there is no reason to change in the future the key. the header will stored on a different place, and goes not out of my safe house, but the date does. i will have a minimum header size, how to do this? cryptsetup is version 2.7.5 should i use luksFormat --type luks1 to get a 2MiB header? or what does --luks2-metadata-size and --luks2-keyslots-size do? how to understand these both options?

I've got a system with LUKS partitions. I'd like to convert them to LUKS2 to see if I can simplify my setup using partition labels. When I run cryptsetup convert --type LUKS2 it seems to work correctly

# cryptsetup convert  --type luks2

WARNING!
========
This operation will convert  to LUKS2 format.


Are you sure? (Type uppercase yes): YES

But then when I attempt to unlock the volume it breaks:

# /usr/local/bin/unlock_password.sh | cryptsetup -v luksOpen  PartB
Command failed with code -1 (wrong or missing parameters).

Converting back to LUKS 1 fixes it

# cryptsetup convert  --type luks1

WARNING!
========
This operation will convert  to LUKS1 format.


Are you sure? (Type uppercase yes): YES
# /usr/local/bin/unlock_password.sh | cryptsetup -v luksOpen  PartB
Key slot 0 unlocked.
Command successful.

Does anyone know why this could happen? It looks like the conversion didn't run correctly on the keyslot, or maybe the input handler is different for LUKS2 and it can't accept my (large, base64) password. My old version of cryptsetup is 2.0.4 if that matches up with known bugs. PS. I have also added a second key-slot with a new random key file. It also stops working when I convert to LUKS2 so it looks like, with my current environment, I cannot convert to LUKS2.

I am trying to create a filesystem in ZFS with the following command: zfs create -o compression=on -o recordsize=1M -o encryption=on pool/dataset I am unable to do so, since I receive the following error: cannot create 'pool/dataset': Keyformat required for new encryption root. There are 3 results for this in Google, none of them are particularly helpful. What am I doing wrong here?

I have been having some issue unmounting my encrypted drive recently. This lead to it being forceably removed instead of ejected. It appears to have some done some damage to the drive as, although I can access some of the data within it, certain portions appear to be missing. Are there any tools I can utilize to attempt to recover any lost data? Thank you so much for any help. Some of the files on this drive are very important to me and I want to ensure I do everything possible in attempting to recover them. And in the future, utilize a more robust method of backing up data.

With cryptsetup I will create some LUKS encrypted files with detached header. In the files I will write once and read repeatedly. I do not need to change any key. How can the size of the header be kept as small as possible?

I want to create a new encrypted LUKS-partition in GParted. I've searched the UI and the help, but the only thing I can find is [how to open and close an _existing_ LUKS partition](https://gparted.org/display-doc.php?name=help-manual#gparted-open-encrypted-partition) and how to [to copy and paste an existing one](https://gparted.org/display-doc.php?name=help-manual#gparted-copy-and-paste-partition) . However, I can find no way to create a new one. I can create a new partition e.g. for btrfs, but it is never encrypted. So it seems for that only task of creating a new partition I have to resort to other tools like _GNOME Disks_ (GNOME Disk Utility), which easily allows this when creating a new partition, or fallback to the commandline, which I'd like to avoid. Or is there any way to create a new encrypted partition? ### Broader use case Actually, i want to do what is described in the GParted help: Copy an encrypted partition and „maintaining an encrypted” partition on a new disk. However, to do so (i.e. to not decrypt the data while copying), I have to paste it „into an existing open LUKS encrypted partition”, i.e. I need to have an encrypted partition first. So, finally, **is there any way to create a _new_ encrypted partition in GParted?**