I suggest using a different testing method. hdparm is a bit weird as it gives device addresses rather than filesystem addresses, and it doesn't say which device those addresses relate to (e.g. it resolves partitions, but not devicemapper targets, etc.). Much easier to use something that sticks with filesystem addresses, that way it's consistent (maybe except ...
"sda5_crypt" crypttab change as per suggestion below:
Replace OLD_NAME with NEW_NAME in /etc/crypttab, and then:
# dmsetup rename OLD_NAME NEW_NAME
# update-initramfs -c -t -k all
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 ...
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 ...
If all you want to change is the hash, there is no need to re-encrypt. You still have to build a new LUKS header though. Same cipher, same master key, same offset, different hash.
You can try this for yourself. First we set up a LUKS device with standard settings and lousy iter counts:
# truncate -s 8M /dev/shm/foobar
# cryptsetup --iter-time=42 luksFormat ...
Yes, of course. The vendor can just keep the master key. A backup of the LUKS header. As this key never changes even as you change the password, it allows full access to all the data. So you are entirely depending on trust here. Backdoors and everything else just come on top of that.
In addition to the manpage, the Cryptsetup FAQ is a good read:
I did a small benchmark. It only tests writes though.
Test data is a Linux kernel source tree (linux-3.8), already unpacked into memory (/dev/shm/ tmpfs), so there should be as little influence as possible from the data source. I used compressible data for this test since compression with non-compressible files is nonsense regardless of encryption.
For changing the file system UUID you have to decrypt /dev/sda1 and then run tune2fs on the decrypted device mapper device.
sda1 itself does not have a UUID thus it cannot be changed.
The LUKS volume within sda1 does have a UUID (which is of limited use because you probably cannot use it for mounting), though. It can be changed with
cryptsetup luksUUID /...
If you (a) have enough free disk space and (b) are using LVM, you could:
Take a backup.
Re-read step 1, not ignoring it this time.
Re-read step 1, keeping in mind I haven't actually tested this. It should work, though!
Shrink your current physical volume (pvresize)
Resize the underlying partition. Unfortunately, in order to re-read the partition table, you'...
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 ...
Each key slot has its own iteration time. If you want to change the number of iterations, create a new slot with the same passphrase and a new number of iterations, then remove the old slot.
cryptsetup -i 100000 --key-slot 2 luksAddKey $device
cryptsetup luksKillSlot $device 1
I think the hash algorithm cannot be configured per slot, it's always PBKDF2 ...
Don't encrypt the whole hard drive (as in /dev/sda, do it per partition (or more precisely per file system - see below).
Have separate file systems mounted at homes for the two users. I'm intentionally avoiding writing separate partitions, since while that is the usual way of doing things, it is constraining in some aspects. It might be more convenient to ...
The LUKS format has multiple key slots, each one may contain the encrypted master key that is used for data encryption. This master key is encrypted using another key which is derived from your passphrase.
Using plain hash_function(passphrase) to generate a key would be dumb as hashes such as sha1 can be calculated fast (SHA-1 is an example of a MAC ...
Plain DM-Crypt looks like random, provided you are using a proper cipher. However you will have to remember all encryption settings by yourself.
DM-Crypt/LUKS has a distinct header which remembers the encryption settings for you and manages several pass phrases; however you can also put this header in an external file instead. As long as it's available at ...
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 ...
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
I think your testing does not match the documentation (man fstrim).
Verbose execution. With this option fstrim will output the number of bytes passed from the filesystem down the block stack to the
device for potential discard. This number is a maximum discard amount from the storage device's perspective, because ...
dd if=/dev/urandom of=/dev/sdx bs=4096 status=progress
This command will overwrite the entire drive with random data. That random data will stay there until you write other data, or secure-erase, or TRIM.
In other words, will the random data that I generated with dd still reside inside of the encrypted partitions that i create?
Normally this is the case....
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. ...
The “filesystem type” in a PC partition is actually a volume type, or more precisely a usage type: it's really supposed to indicate which operating system the partition belongs to (e.g. Windows vs Solaris vs FreeBSD), and what it's supposed to do with it (e.g. nested partition of some kind vs filesystem vs swap). In practice, different OS vendors have made ...
If you do not have backups, your data wasn't important.
It's gone. There is no undo. Especially not with encryption involved.
something that produces output > /dev/somedisk overwrites data on the device. Whatever is overwritten can not be restored, so your only chance would be if you noticed and cancelled it right away. Then probably only the first few ...
The short answer is that encrypted volumes are not really more at risk.
The encrypted volumes have a single point of failure in the information at the beginning of the volumes that maps the password (or possibly several passwords for systems like LUKS) to the encryption key for the data. (That is why it is a good idea to encrypt a partition and not a whole ...
It depends on your point of view. It's more secure since keyfiles usually are truly random while passphrases tend to be short and weak.
Then again a passphrase, on its own, takes about $5 to break, either using a keylogger dongle or modified bootloader/initramfs or the infamous XKCD decryption wrench. Same is true for keyfiles if it's only that file on the ...
Recent Intel and AMD processors have a cryptographic accelerator called AES-NI. This can provide a visible speedup when encrypting a large volume of data. It's up to you to decide whether a speedup in encryption is worth buying a more recent processor.
The default cipher is somewhat conservative. When creating the encrypted volume, pick AES as the cipher (...
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.
mint_root /dev/sda5 none ...