There is no point in doing multiple passes. Once is enough.
Filling a to-be-encrypted drive with random data mainly has two uses:
get rid of old, unencrypted data
make free space indistuingishable from encrypted data
Usually if you encrypt you don't want anyone to see your data. So chances are, if you had old, unencrypted data on this drive, you want to ...
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 ...
This is an entirely nonsensical endeavour. If you choose a password that is so easy that I might be able to guess it with 5 or 6 attempts, you might as well not use disk encryption at all.
On the other hand, a password that cannot be guessed in under half a dozen attempts and would trigger this "lock out security measure" is of no avail either.
One of the best ways to do this is to use a smart card with a crypto key on it to unlock the keys for your encrypted block devices. You will only need to enter the passphrase (called "PIN" by the tools but it's really a passphrase) once, after which it will be cached. This has the added advantage of protecting the encrypted data with something-you-have (the ...
My solution to LUKS and keyboard layout problems is to add the passphrase twice. So the same sequence of key presses will be accepted in both US/qwerty layout and whatever you usually use (in my case, DE/qwertz).
If you use more than one keyboard layout you can add more passphrases for them; LUKS supports up to 8 in total, and most people never use more ...
At least with the Fedora 20 package qemu-img (1.6.2, 10.fc20) does not use AES-NI for AES crypto.
One can verify it like this:
Does the CPU have AES-NI?
$ grep aes /proc/cpuinfo -i
For example my Intel Core 7 has this extension.
Install the necessary debug packages:
# debuginfo-install qemu-img
Run qemu-img in a debugger:
$ gdb --args ...
As the man page states, it's game over.
Removing the last passphrase makes the LUKS container permanently
That is, if you really removed the last key. Does cryptsetup luksDump show DISABLED for all key slots?
Normally cryptsetup prevents you from doing that, or at least asks for confirmation:
# cryptsetup luksRemoveKey foobar
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 ...
Your first approach appears to encrypt everything except /boot; your second approach encrypts only swap & home.
I suggest encrypting everything. I believe Debian can handle even /boot being encrypted nowadays (with grub prompting for a passphrase).
There are a few big advantages to encrypt everything:
Security. It's far too easy for data to ...
You can bind encrypted data to a specific device using a Trusted Platform Module (TPM). These have become quite common in x86 laptops over the last few years, and can be installed in many servers too.
Using a TPM, you can generate an encryption key which only exists in the module, and encrypt data using that; if you generate a key which can't be backed up, ...
No, that would not make sense.
A delay between attempts makes sense for online uses of passwords, for example to authenticate into a system. It makes sense when you have to go through a software “gateway” in order to access the system. After an incorrect attempt, the gateway can delay or block further attempts from the same origin. The delay works because ...
Not the way you describe, so @Damon's answer is correct.
But if you don't mind waiting regardless whether you know the password or not, you can crank up the iteration time of cryptsetup/LUKS to a very large value, even to 10 minutes if you think you need that much. That way the "lockout" would always be in effect, regardless of your attempts.
You will need to use a different user than the account that you are setting up encryption for (this is primarily the 'root' user but could be any user who has access to 'sudo'). Do the following:
Install these packages: "apt-get install ecryptfs-utils cryptsetup"
Run the following using either root or a user with root privileges: * "ecryptfs-migrate-home -u ...
The solution given to this question over on SuperUser deserves its own cross-reference here. Note that this answer here is a Community Wiki so none of us get credit for the replication.
How to access a BitLocker-encrypted drive in Linux?
The Github code checkins are recent so - as of May 2016 - this is still an active project.
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 ...
Have you tried something similar to this from for example a live OS or rescue boot menu from a linux installation media (cd dvd usb etc...)
$ sudo cryptsetup luksOpen /dev/sd<yourEncryptedDiskId> <aNameThatwillBeCreatedIn:Dev/mapper>
Like for exemple :
$ sudo cryptsetup luksOpen /dev/sda tmpData
$ sudo mount /dev/mapper/<...
If you have the AES-NI instructions set in your CPU, then it is also hardware accelerated.
Also I don't see a difference between BitLocker and LUKS. It's a similar approach but at least LUKS is open source, so I tend to trust that better.
And I would trust more LUKS than the OPAL hw standard found in some HDD/SSD. At least it is better auditable. If the ...
It might be worth looking at the Filesystem Hierarchy Standard which describes what the various filesystems are generally for (from a standards perspective, not everyone has to follow it), which will let you know where personalised data might be stored. However, the short answer is - anywhere an application wants to store it, and has permission to store it.
It's possible to simply store the luks password in a file.
I use this on my home computer; The root file system lives on a regular luks volume which I unlock with my passphrase at boot. An additional drive contains a luks volume with a generated password.
This additional volume is unlocked by a password file which lives on the encrypted root file system. ...
So, without opening the whole topic of deniable encryption (and the cryptsetup FAQ has a section dedicated to that topic too) and since you're asking to simply hide the LUKS device (if that's sufficient), I'd use the luksHeaderBackup and luksHeaderRestore options from cryptsetup(8).
Example for an already created LUKS device with an ext4 file system on it:
I ended up getting this fixed.
Basically, I needed three partitions rather than two:
ESP (FAT, unencrypted)
/boot (ext, unencrypted)
/ (any valid Linux file system, encrypted)
The unencrypted EFI system partition (ESP) only contains the bootloader (e.g. GRUB), not the kernel or its initrd/initramfs (initial ramdisk image containing the kernel). The ...
You will need to use different windows/linux system encryptions and then use a common data partition with veracrypt and possibly fat or ntfs (as far as i know there is no ext driver for windows anymore due to enforced driver signatures. NTFS is not the best choice for linux, but may have advantages in windows).
If you want to encrypt windows with veracrypt, ...
Here is my workaround on debian, given the bug referenced above by @sebasth.
My setup is slightly different. I have an encrypted root partition and a bunch of raid disks. For me, I had to add a initramfs option to the crypttab:
<target> <source> <keyfile> <options>
part1_crypt /dev/disk/... crypt_disks ...
[On the off-chance that there's not something funny about this question, maybe there's a legitimate language barrier or some other issue,
might as well make it an "official answer"]
You might want to make a backup of eCryptfs's important files too, in /home/.ecryptfs/<user>/.ecryptfs/ especially the wrapped-...
Is it possible to encrypt a btrfs subvolume only (no need to be
No, BTRFS does not currently have built-in support for encryption. Today, to encrypt a filesystem (not just a sub-volume) you'd need DM-Crypt/LUKS. See https://btrfs.wiki.kernel.org/index.php/FAQ#Does_btrfs_support_encryption.3F
Mounting the drive
(I use a USB-casing for SATA drives, you might as well install the drive in your PC)
When encrypting the disk while installing Mint the drive will contain a partitioning scheme (using fdisk -l /dev/sdb) such as
/dev/sdb1 -> Bootable, about 500M in size, Id 83, Type "Linux"
/dev/sdb2 -> Not-bootable, rest of your disk's capacity, ...
From the LUKS faq https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#2-setup
2.5 Can I encrypt an already existing, non-empty partition to use LUKS?
There is no converter, and it is not really needed. The way to do
this is to make a backup of the device in question, securely wipe the
device (as LUKS device initialization ...
/root is normally on the root partition. It's meant to be available even if something goes wrong and other partitions can't be mounted.
Note that /root only contains what you put yourself. Sensitive data created by the system ends up under /etc or /var.
These days, with most CPUs having accelerated AES instructions, disk encryption is very cheap. So if you'...
Everything you need is already built into mount.
The user option will allow non-root users to mount it
also add noauto to stop mount attempts during system startup.
/foo/bar /home/me/wherever none user,noauto,bind 0 0