Security :: Dm-crypt Aes-xts-plain64 Vs Aes-cbc-essiv For Volumes > 2TiB?
Sep 12, 2010
I'm not a mathematician or cryptographer, only an end user of the technology trying to determine the "best" or safest future proof option to go with for long term archival while also maintaining reasonable performance with dual opteron ~2GHz or similar setup. I've noticed aes-cbc-essiv seems to be the default choice in various installers for reasons of backwards compatibility while others are moving towards XTS since the standardization.
I'm simply interested in a more basic discussion of why one would choose one of these methods over the other. What do they offer that the other does not? I'll start with what I know:
- dm-crypt/LUKS --- included in a lot of install images already; in other words, perhaps easier to implement on a fresh install - TrueCrypt --- multiple encryption algorithms possible
[code]....
For me... I have no need for Windows compatibility, though I do use OS X on a dual booting MacBook. I believe TrueCrypt woks with OS X, so that could be a bonus, though I can simply encrypt my home folder on OS X with it's own FireVault and be fine.My setup (after wiping and starting over) will probably be like so:
- /boot on it's own primary partition - / on it's own primary partition with logical partitions within --- /usr, /var, /etc, /opt, and the like on a logical partition --- /home on a logical partition
/home will surely be encrypted and I'm leaning toward encrypting the rest as well, though perhaps it's not necessary. I'm open to input there as well -- is there anything the leaks from normal application use into /var or /tmp that would make one lean toward just encrypting the whole thing?
I opened up TrueCrypt just to look at it and since I can't encrypt a whole partition without losing data... I pretty much have to encrypt from what? A live CD? This could be a drawback -- I think since TrueCrypt isn't coming on install disks, I'd have to go with an unencrypted (or dm-crypt/LUKS) root partition and then use TrueCrypt to make a container (or partition) for /home only. I can't think of another way to do this since I can't encrypt the whole disk as one entity with my dual booting situation...
I have a perfectly OK 2.5 inch disk drive from a dead laptop (graphics card failed).
The hard drive is fine. I know the passphrase.
I had installed Ubuntu 10.04 with full fisk encryption using dm-crypt/luks using the alternate install cd.
I'm not exactly sure of the configuration I selected. Just that its full disk encryption with a pre-boot passphrase prompt.
Now my issue is, I have put the drive into a usb drive docking station, and I simply want to mount the partition on my new laptop, so I can copy the files over.
I've tried googling for various things like "mount dm-crypt drive linux" and "how to mount a luks encrypted partition linux", but I get no results.
When I upgraded from FC11 to FC12 of the encrypted raid partitions started to request password on boot (in FC11 not having references to encrypted md1 in fstab and crypttab, was enough for FC11 not to ask for passwords on boot) despite the fact that I removed /etc/crypttab and there is nothing in /etc/fstab relating to encrypted md1 (raid array). I want my machine to boot w/o asking me passwords for encrypted devices, and I will open and mount them myself manually after boot.
I'm trying to have a LUKS encrypted partition mounted at startup and to have GDM ask for my key so it will decrypt. Now I followed [URL] to the letter. Except for now, I have it just mounted into /mnt/cryptohome so I'm not messing with my system. My problem is the one everyone mentions in the comments, ubuntu isn't asking for the LUKS key in the X display, it's asking in the first terminal (Ctrl-Alt-F1). This will not do. I need it to ask to mount my drive before I'm even asked to login, so eventually I can encrypt my /home.
I'm just wondering - what is the best way to set up your encrypted volumes with dm_crypt and LUKS?
My understanding was that aes-lrw ws better than aes-cbc - and then I stumble upon [url] which says that LRW has some problems, and XTS is better? I dont know enough about encryption theory to be able to say anything, so i'm hoping some folks more enlightened will be able to say something here.
I was previously using aes-lrw-benbi to set up a volume. If xts is truly better - should i be using '-c aes-xts-benbi' then?
TrueCrypt hidden volume plausible deniability is documented at [URl]deniability but how plausible is it? there is no sign of the hidden volume's existence within the outer volume even if the user is forced to disclose the outer volume password. For this to be plausible the outer volume must be used or the user has no plausible reason for having it.
Quote:
If you mount a TrueCrypt volume within which there is a hidden volume, you may read data stored on the (outer) volume without any risk. However, if you (or the operating system) need to save data to the outer volume, there is a risk that the hidden volume will get damaged (overwritten). To prevent this, you should protect the hidden volume in a way described in this section.
The way described results in the outer volume properties including 'Hidden volume protected: Yes' which discloses the hidden volume's existence. The next section in the documentation has a diagram showing how the hidden volume is created at the top end of the outer volume space. Use of the outer volume must not write in the hidden volume space or the hidden volume will be corrupted. That limits the choice of outer volume file system to one of the FAT series because more sophisticated file systems do write in places across their whole space.How plausible is the choice of a FAT file system on Linux? Even on a dual boot system with the usual Windows versions NTFS is a better choice.
In Nautilus I select a directory on local NTFS volume. I'm logged in as root, right-click > Properties > Permissions and I set "Others" to "none". But it doesn't work. I want my friends & visitors to use and enjoy Ubuntu but without access to my NTFS volumes.
I have a system, I want only my sudoer account to show and automount NTFS partitions under 'Places' in Ubuntu. Simply, they shall not have access to mount it. Only my main sudoer user account shall take advantage on this show-and-possibly-automount feature of GNOME, but not anyone else.
I'm running 10.04 running daily updates. A couple days back, I saw an update related to mounting volumes. Not sure if this is what broke my system, but might be. When attempting to mount a partition from nautilus, I get a message saying I do not have authorization. It does not even ask for my password, just fails. I tried running updates and this asks for my password and accepts it fine. I opened disk utility from the menus and tried to mount the volume from there but also got the same permission denied, not authorized without even being asked for my password.
I then ran gksu palimpsest. I was asked for my password and was able to mount and unmount partitions from there. However, when mounted, my applications and nautilus cannot access the data in the partitions mounted using gksu palimpsest. In nautilus, I can navigate to /media/Data (the partition in question) but I get "THE FOLDER CONTENTS CANNOT BE DISPLAYED You do not have the permissions necessary to view the contents of "Data"." When I open nautilus via gksu in the terminal, I do have full access to the partitions.
How do I get my privileges back for my user account. I am the only user on the computer, and I have never set up a root account since my upgrade to 10.04 months ago. I tried of course the Administration->Users and Groups menu, but I am not permitted to change the account type or open advanced settings. I click the button, but nothing happens, not even a password request. Running gksu admin-settings on the terminal allows me access. My current settings are attached.
I have had for a test installed Feodora but was so silly checking the box for encryption the HD. Now I tested all for removing Feodora (no data anymore on the disc) but even the test unlocking this from my ubuntu system failed with the following error:Error unlocking device: cryptsetup exited with exit code 251: Command failed: Failed to setup dm-crypt key mapping.Check kernel for support for the aes-xts-plain64 cipher spec and verify that /dev/sdb2 contains at least 508 sectorsI installed some encryption packages in the meantime - but non was helpful.Would some kind person - who understands this better than I - please provide the detailed steps needed to mount and unlock the encrypted Feodora installed hard disc. Maybe one of you know which packege I have to install.
The in build cipher algorithms that are in the kernel are not critically secured, the best, I think, supports 384 bit encryption.
So I was looking forward towards stuff like DSA or very preferably OTP cipher with like... 8192 bit encryption using DM, I know it sounds insane, but so is the data. I want it to be uncrackable for the fastest supercomputer combined till 2070.
At first the problem was that the old volume group (containing all logical volumes for both physical volumes) had the same name as the new volume group. I did a reinstall where I changed the name and ran vgreduce --removemissing debian which seems to have removed all logical volumes from the old volume group.
When I try to unlock the drive in Gnomes Disk Utility I get "Incorrect Passphrase. Try again." but I *know* it's the right password, and I don't get any error when changing the password so that seems to be possible.
I found the oldest archive in /etc/lvm/archive/ and manually edited it to remove any stuff about the old LVs and PVs. Then I did vgcfgrestore --file VG_backup.vg groupname. With the help of blkid I edited /etc/fstab and /etc/crypttab to mount the disk at startup.
I can't believe that I did not write down the password to my encrypted volume. Had not rebooted in a long time so I had not typed it and now that I rebooted I don't remember what is was.
Is there any way to automate the trial of different passwords? I remember the basic structure of what the password was so if somehow I could automate trying passwords from a list I may have a good change to recover my volume.
If/when I do remember the password. Is there a way to change the password on an encrypted volume? I need to make it something I will remember for sure... or write it down somewhere safe..
I have a compressed backup that I want to crypt and upload to a remote server through ssh once in a while. The problem is with the size, more than 4 GB. If the connection drops how does scp know to resume? This should be an automated process.
Since i'm on-the-road a lot encryption is crucial, with windows i've always used TrueCrypt and DiskCryptor, this is very easy to setup and allows me to create usb/cd devices that i can boot off and contain a keyfile, on boot it also requires a passphrase. Currently all i need to do is boot from harddisk and enter my passphrase. I would like to be able to boot from external device (in this case USB) that contains the bootloader and an integrated keyfile, also it should requist the passphrase. I found a guide on how to achieve two-factor authentication with dm-crypt on feisty but it's quite an old guide and is realy realy complicated for a newbie
I just bought a new laptop which will be running SSD (Corsair 120GB) as the boot drive and would like to migrate my OS to the new system. One of my requirements is full-disk encryption. I work with proprietary client data and need to encrypt the new drive, its swap partition, everything except for /boot. I've read instructions for doing this from the alternate install CD, but my OS is disturbingly customized (started out as 10.04) and it would take months to rebuild everything. I keep remastersys (-dist) ISOs to ensure I don't have to go through that process, but the ubiquity installer does not appear to have the option of doing disk-level crypt during the installation process. I can boot the ISO into CLI, but don't know how to run the alternate installer from there.
It seems I've run into a bit of a problem. I recently upgraded to the latest kernel 2.6.32-24-generic (x86) but when I reboot into the new kernel and type in my password the system hangs, same when using a keyfile on the root file system.to give an outline of how the disks are setup.3 hard drives
I'm trying to manually boot (from the GRUB console) into a system set up as follows: crypt partition -> LVM -> root LV, and I'm having some trouble figuring out how to do this from the GRUB console.
I have successfully manually booted a system which is set up as just LVM -> VG -> root LV. All I have to do is load the LVM module. In GRUB, that partition shows up as (hd0,gpt5). Once I load the GRUB LVM module, I can see the logical volume within the LVM as well. (My volume group name is "caesar", and the single logical volume is named "root".)
Code: Select allgrub> ls ... (hd0,gpt5) ... grub> insmod lvm grub> ls ... (lvm/caesar-root) ...
It's fairly simple to manually boot:
Code: Select allgrub> set root=(lvm/caesar-root) grub> linux /vmlinuz root=/dev/mapper/caesar-root grub> initrd /initrd.img grub> boot
Where I am having difficulty is in trying to insert crypt before LVM. I can set up such a scheme, and put a minimal installation on it, without issues. It's booting into it upon reboot that I can't figure out. Once I load the GRUB crypto, cryptodisk and luks modules, I can mount the crypto partition:
Attempting to decrypt master key... Enter passphrase for hd0,gpt5 (<long hex string here>): <type my password> Slot 0 opened grub> ls ... (crypto0) ...
At this point, GRUB sees the crypto partition as (crypto0). But the GRUB LVM module doesn't see "inside" of the crypto partition, so I don't see the root logical volume within the LVM listed; all I see is (crypto0).
Code: Select allgrub> insmod lvm grub> ls ... (crypt0) ...
Setting it as root doesn't work:
Code: Select allgrub> set root=(crypto0) grub> ls / error: disk `crypto0' not found.
So, How do I get GRUB to "see" LVM inside the crypto partition?
I managed to setup an encrypted partition that's mounted on boot using dm-crypt/LUKS.
The relevant entry from my /etc/fstab:
/dev/mapper/st_crypt /media/st ext4 defaults 0 2
The partition is mounted at boot, and I can write to it as root just fine, but I have no idea how to make it writable by a normal user (i.e the users group).
After upgrading to Natty Narwhal my Crypt Keeper app will not launch. I am now unable to access secure files. Has anyone had this issue after their upgrade to Natty Narwhal? If so, How were able to resolve this issue.
I have done a recent install of Debian squeeze on a laptop. I set up LVM with 3 LV's, one for the root filesystem, one for /home, and another for swap. I then used lvextend to increase the size of the LV's. This additional space is shown if I enter lvdisplay (shortened for clarity):
However, if I use df, it still shows the previous size. /dev/mapper/auriga-root 14G 8.0G 5.2G 61% / /dev/sda1 221M 16M 193M 8% /boot /dev/mapper/auriga-home 147G 421M 139G 1% /home
I have even tried restarting as well. I do not understand why df would still show that /home is 147GB, when I extended it to 169GB using lvextend. Similarly for the root, which was extended by 2GB from 14GB to 16GB.
I was finally upgrading from F12 to F14, and as you'd expect from someone posting for the first time here, I did something stupid. My system has two drives set up as RAID-1 with LVM for the entirety of them. I added a new drive to use as the boot & OS drive, but during the install process I believe I somehow managed to wipe the LVM information from the RAIDed drives (though I did not install to them or format them).
While I have a working F14 install on the new drive, I would like to get access to the data I have on the RAID. However, the LVM tools show the RAID drives as uninitialized. If I try booting off the RAID, it gets partway through the bootup (the white part of the progress bar gets about halfway) before displaying "No root device found. Boot failed, sleeping forever." This occurs regardless of whether I have the new drive plugged in or not. I've been googling for the past several hours and haven't found anything that allows me to access the the volumes on the RAIDed drives.
First Question: I have a very big volume (20+TB). When I try formatting it as ext4, I get the error message:
mke2fs 1.41.12 (17-May-2010) mkfs.ext4: Size of device /dev/sdc1 too big to be expressed in 32 bits using a blocksize of 4096. I understand that ext4 has a limit of 1EB (about a million terabytes), but a 32-bit limitation in e2fsprogs prevents me from creating a partition > 16TB.
Until e2fsprogs is updated to use 48-bit block addressing, it appears my choices are:Break up the volume into smaller volumes < 16TB, or Use xfs or zfs (I have already created a test xfs partition, and it works fine).
Does anyone have any opinions about which option is preferable? I have never used xfs before. Is it as robust as ext4? Is it as well supported by Ubuntu? What about zfs? Is it worth downloading from the ppa?
Second Question: I now have a huge amount of data to back up. In the old days, I remember making a full backup of a "big" 10 MB hard drive by taking a stack of floppies and inserting them one at a time into my floppy drive while my backup program split the backup into 1.4 MB chunks small enough to fit on a floppy.
I now have the same problem, but at a different scale. I need to back up 20+TB onto a stack of external 2TB drives. Is there any software package that can fragment a backup in this way?
So after installing Ubuntu 11.04 with Fedora Beta 15, I decided it would be a good idea to get a *buntu based distro in case of anything. So I reinstalled it in the form of Xubuntu, and I see that Grub found my Windows 7 install, but not my Fedora install! Here is the output of fdisk -l:
