Hot answers tagged luks
7
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 ...
6
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 ...
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
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:
...
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 ...
4
Between 1 and 2, 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 Nautilus, even after resizing with ...
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
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 ...
4
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 ...
3
Yes, you can find the information in /sys/block/$DEVICE/slaves. If you only have the canonical name you can use readlink to get the details, e.g:
devdm="$(readlink -f /dev/mapper/extern-1-crypt)"
dm="${devdm#/dev/}"
ls /sys/block/$dm/slaves/
If you want to remove all you can just utilize directly the sys filesystem:
echo 1 > ...
3
There's a evident wrong configuration:
lvm_crypt /dev/sda5 none luks
You decrypted the volume and named it lvm_crypt while mounting /dev/mapper/mint-root
Were you asked to input the password during boot ?
Also, did you updated initramfs afterwards ? Because this crypttab need to be embedded since it's for root partition.
EDIT
mint_root /dev/sda5 none ...
2
You might be stuck using a kickstart to define the partition with the encryption type instead of using the graphical install interface.
2
Tried my best to stay posix with this, note that it will fail if you do not have a suitable "udevadm" package available for displaying udev info.
#!/bin/bash
command_exists () {
type "$1" &> /dev/null
}
CMD=""
if command_exists udevadm; then
CMD="$(which udevadm) info -q all -n"
fi
if command_exists udevinfo; then
CMD="$(which ...
2
You should definitely go with luks as it is integrated with the Linux kernel and will work out of the box. Using other solution is not really worthwhile especially since some of them won't support AES-NI.
For a discussion about what to encrypt have a look at Any reason for encrypted /? but depending on your paranoia level and security needs just encrypting ...
2
I don't think something like this exists right out of the box, but it should be possible. I'll put together some references for you.
First there's /etc/crypttab - typically you specify a key file or password in the third slot, but some distros allow you to specify an option in the fourth field called keyscript (debian and opensuse support this: ...
2
Short answer: No.
You could have multiple keys in different slots , but that's not related to your question.
For security ， I maintain a checksum for ramdisks and cryptsetup is statically linked ， and I check them automatically everytime I boot.
UPDATE
The checksum is stored on encrypted FS , you can't modify it until you mount that partition.
That is , ...
2
The dropbear (ssh server) is supposed to be started very early during boot phase - earlier than the init (rcN.d) sequence and firewall init scripts; even earlier than / is mounted (it is encrypted too, right?). So it comes to initramfs, the pre-/ userland loaded for kernel by boot loader. The image is (re)generated by update-initramfs -u from contents of ...
2
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 ...
2
If you want a per user encryption, Ubuntu already offers a solution for that I believe. It doesn't use dm-crypt/luks but ecryptfs or similar, to encrypt each users home directory individually, using an encrypted layer on top of the regular filesystem.
As for dm-crypt/luks, you'd have to create a separate partition or logical volume for each user to achieve ...
2
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 ...
2
There is a lot of possibilities:
:> # 1
:> pvscan
:> # 2
:> vgscan -v extern-1
:> # 3
:> dmsetup table /dev/mapper/extern-1-crypt
:> # 4
:> cd /sys/devices/virtual/block/
:> for dmdev in dm-*; do
:> if [ xyz = $(< "${dmdev}/dm/name") ]; then
:> ls -l "${dmsev}/slaves/"
:> fi
:> done
Or take the "dm-" ...
2
You can use gpart to search for file systems on /dev/dm-2. After that or even as an alternative you can create dm volumes without LVM using dmsetup directly. On my systems the first LV always starts at offset 384:
dmsetup create restore-lv --table "0 25165824 linear /dev/dm-2 384"
The size is not important (and usually wrong) for the test. Then you check ...
1
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. ...
1
The intent of luksSetup is to be used when the device is still in use, but you want to temporarily lock all accesses to it until the passphrase is entered from an external source. Thus it doesn't make much sense to only call luksSetup when the device is unused: if it's unused, close it with luksClose.
There's no way to atomically enforce that the device is ...
1
I did something similar to this once with a remote encfs where I stored backups from my local PC. Maybe this will help. I was using Ubuntu with gnome-keyring at the time.
dbus_session.sh
#!/bin/bash
# This will grab the appropriate environment variables to connect to the
# gnome-keyring via dbus for the currently logged in user
# shouldn't be necessary ...
1
This isn't supported out the box, but you probably can hack something together. The idea is to seal the LUKS key in the TPM, and then set up a trusted boot path which unlocks the sealed key. You'll need to install TrustedGRUB, and write a keyscript for /etc/crypttab which retrieves the key from the TPM. This will all happen in the initrd, so that will ...
1
Tape devices are not suited for random access (they don't provide random-access), i.e. they are not block devices. And LUKS is designed for block devices, like e.g. XFS is a filesystem for block devices. You can't mkfs.xfs on a tape device, can you?
Thus, go with the OpenSSL streaming cipher encryption via pipe approach, like suggested by Ignacio.
Similar ...
Only top voted, non community-wiki answers of a minimum length are eligible
