Re: Linux disk partition encryption
Celejar schreef: On Wed, 26 Jan 2011 23:24:07 +0100 Jochen Schulz m...@well-adjusted.de wrote: Celejar: Brad Alexander stor...@gmail.com wrote: Linux admins used LUKS, and as a further step, I put /boot (the only partition that cannot be encrypted) on a USB stick, so that if anyone got the laptop, they had no access to the data. Why does putting /boot on a USB stick gain you anything? Because an unencrypted /boot may be altered by an attacker without you noticing it. Theoretically, the kernel may be replaced by another one that reports your passphrase to the attacker. Oh, basically the Evil Maid attack. Fair enough. But then you have to make sure the attacker can't flash the BIOS ... Bother to explain how it works? If you have an encrypted partition, no adapted kernel will ever be able to access it. So how can an adapted kernel report the passphrase? Or do you mean that the kernel can be altered to log the passphrase somewhere? This then is a way more general problem, as physical access to the computer will always allow someone to install a sniffing hardware or software device. Sjoerd signature.asc Description: OpenPGP digital signature
Re: Linux disk partition encryption
On Qua, 26 Jan 2011, Brad Alexander wrote: Because if your laptop gets stolen, the odds are that they will not get the USB drive. Thus, it is another layer of security. Plus, if they have /boot, they will be prompted for the passphrase, which means they can brute force it. Only if the user is using a dumb passphrase like password or 123456. Or if the attacker can wait years (or decades) for the data. Moreover, if the user wants the data (which is not so common, but could happen), not having a /boot does not prevent brute force attacks. One just needs to remove the hard drive and try to mount in another system, and they'll get the same passphrase prompt. -- Tempt me with a spoon! Eduardo M KALINOWSKI edua...@kalinowski.com.br -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127092751.4925343au6hfq...@mail.kalinowski.com.br
Re: Linux disk partition encryption
On Thu, 27 Jan 2011 11:03:58 +0100 Sjoerd Hardeman sjo...@lorentz.leidenuniv.nl wrote: Celejar schreef: On Wed, 26 Jan 2011 23:24:07 +0100 Jochen Schulz m...@well-adjusted.de wrote: Celejar: Brad Alexander stor...@gmail.com wrote: Linux admins used LUKS, and as a further step, I put /boot (the only partition that cannot be encrypted) on a USB stick, so that if anyone got the laptop, they had no access to the data. Why does putting /boot on a USB stick gain you anything? Because an unencrypted /boot may be altered by an attacker without you noticing it. Theoretically, the kernel may be replaced by another one that reports your passphrase to the attacker. Oh, basically the Evil Maid attack. Fair enough. But then you have to make sure the attacker can't flash the BIOS ... Bother to explain how it works? If you have an encrypted partition, no adapted kernel will ever be able to access it. So how can an adapted kernel report the passphrase? Or do you mean that the kernel can be altered to log the passphrase somewhere? This then is a way more general problem, as physical access to the computer will always allow someone to install a sniffing hardware or software device. I think we're talking about the latter - the attacker replaces your kernel with a modified one to record the passphrase. Yes, it's basically true that an attacker with physical access can always install a sniffer, but forcing him to do it in hardware will make it harder. http://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127085238.c1e2f215.cele...@gmail.com
Re: Linux disk partition encryption
Sjoerd Hardeman: Celejar schreef: Oh, basically the Evil Maid attack. Fair enough. But then you have to make sure the attacker can't flash the BIOS ... Bother to explain how it works? If you have an encrypted partition, no adapted kernel will ever be able to access it. Of course it can. You are entering the passphrase as usual and besides working as usual, your kernel performs a few extra tasks. J. -- I think the environment will be okay. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Linux disk partition encryption
On Thu, 27 Jan 2011 05:25:20 + (UTC) T o n g mlist4sunt...@yahoo.com wrote: Thanks everyone who commented. On Thu, 27 Jan 2011 00:07:21 +0100, tv.deb...@googlemail.com wrote: - First very noob question, I don't want whole disk encryption, just want to encrypt some selected already partitioned partitions. If someone mount those encrypted partitions, will they shows up as empty or, there are some hints that the partitions have been encrypted? Don't know what you mean exactly by show up as empty, with ecryptfs the mountpoint will indeed be empty unless the crypted directory is open. . . My this question seems to have confused most people. What I wanted to know is how would the partition appears to normal Joe. Now my understanding is the following. are they correct? The encrypted partition will appear as unformatted -- with no files system on it, if you just simply want to do 'mount /dev/sdx' (just like how Linux partitions normally appear to Windows). Even if one read its physical sections, they will appear as random numbers. Oh, wait, cryptsetup, has a pretty standard header, so an expert can at least tell that the partition is encrypted with cryptsetup, but whether he can decipher or not is a different story. Is about correct? Pretty much, although I'm no expert. Further, does disk encryption access the partition directly? I mean, does the 'cryptsetup luksFormat /dev/sdxn' care what type of partition (ext2/3, fat, etc) /dev/sdxn is? You seem to be confusing partitions with filesystems here. cryptsetup works on raw partitions - the filesystems go on top of the encrypted volume: /dev/sdxn - luks volume - filesystem Now another question, which nobody seems to have noticed/mentioned. Since CBC encryption is a recursive algorithm, the encryption of the n-th block requires the encryption of all preceding blocks, 0 till n-1. [1] Now, does it mean if my HD has a bad block in the middle, then all the remaining data will be gone entirely? 1. http://clemens.endorphin.org/LinuxHDEncSettings This seems correct - Wikipedia also says that with CBC: Note that a one-bit change in a plaintext affects all following ciphertext blocks. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29 Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127090252.3fbfae63.cele...@gmail.com
Re: Linux disk partition encryption
On Qui, 27 Jan 2011, Celejar wrote: Now another question, which nobody seems to have noticed/mentioned. Since CBC encryption is a recursive algorithm, the encryption of the n-th block requires the encryption of all preceding blocks, 0 till n-1. [1] Now, does it mean if my HD has a bad block in the middle, then all the remaining data will be gone entirely? 1. http://clemens.endorphin.org/LinuxHDEncSettings This seems correct - Wikipedia also says that with CBC: Note that a one-bit change in a plaintext affects all following ciphertext blocks. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29 That is correct, but the whole disk is not one single CBC-encoded unity. The link in the question message says that: [...] CBC chaining is cut every sector and restarted with a new initialisation vector (IV), so we can encrypt sectors individually. The choice of the sector as smallest unit matches with the smallest unit of hard disks, where a sector is also atomic in terms of access. http://clemens.endorphin.org/LinuxHDEncSettings -- Support Mental Health. Or I'll kill you. Eduardo M KALINOWSKI edua...@kalinowski.com.br -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127120639.157859g74gcma...@mail.kalinowski.com.br
Re: Linux disk partition encryption
On Thu, 27 Jan 2011 12:06:39 -0200 Eduardo M KALINOWSKI edua...@kalinowski.com.br wrote: On Qui, 27 Jan 2011, Celejar wrote: Now another question, which nobody seems to have noticed/mentioned. Since CBC encryption is a recursive algorithm, the encryption of the n-th block requires the encryption of all preceding blocks, 0 till n-1. [1] Now, does it mean if my HD has a bad block in the middle, then all the remaining data will be gone entirely? 1. http://clemens.endorphin.org/LinuxHDEncSettings This seems correct - Wikipedia also says that with CBC: Note that a one-bit change in a plaintext affects all following ciphertext blocks. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29 That is correct, but the whole disk is not one single CBC-encoded unity. The link in the question message says that: [...] CBC chaining is cut every sector and restarted with a new initialisation vector (IV), so we can encrypt sectors individually. The choice of the sector as smallest unit matches with the smallest unit of hard disks, where a sector is also atomic in terms of access. http://clemens.endorphin.org/LinuxHDEncSettings Ah, ok. Thanks. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127092054.1c13c435.cele...@gmail.com
Re: Linux disk partition encryption
On Thu, Jan 27, 2011 at 03:06:39PM CET, Eduardo M KALINOWSKI edua...@kalinowski.com.br said: On Qui, 27 Jan 2011, Celejar wrote: Now another question, which nobody seems to have noticed/mentioned. Since CBC encryption is a recursive algorithm, the encryption of the n-th block requires the encryption of all preceding blocks, 0 till n-1. [1] Now, does it mean if my HD has a bad block in the middle, then all the remaining data will be gone entirely? 1. http://clemens.endorphin.org/LinuxHDEncSettings This seems correct - Wikipedia also says that with CBC: Note that a one-bit change in a plaintext affects all following ciphertext blocks. http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation#Cipher-block_chaining_.28CBC.29 That is correct, but the whole disk is not one single CBC-encoded unity. The link in the question message says that: [...] CBC chaining is cut every sector and restarted with a new initialisation vector (IV), so we can encrypt sectors individually. The choice of the sector as smallest unit matches with the smallest unit of hard disks, where a sector is also atomic in terms of access. http://clemens.endorphin.org/LinuxHDEncSettings take a look to the output of cryptsetup luksDump. Here it says XTS-plain64 is used. See http://en.wikipedia.org/wiki/Disk_encryption_theory for explanations on disk encryption schemes. CBC would be a very bad idea for random access and modification. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127154039.gd12...@rail.eu.org
Re: Linux disk partition encryption
On Thu, 27 Jan 2011 16:40:39 +0100, Erwan David wrote: CBC would be a very bad idea for random access and modification. I thought so. Thanks for the confirmation. -- Tong (remove underscore(s) to reply) http://xpt.sourceforge.net/techdocs/ http://xpt.sourceforge.net/tools/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/ihsa4e$bvu$1...@dough.gmane.org
Re: Linux disk partition encryption
On Thu, 27 Jan 2011 15:25:40 + (UTC) T o n g mlist4sunt...@yahoo.com wrote: On Thu, 27 Jan 2011 09:02:52 -0500, Celejar wrote: Further, does disk encryption access the partition directly? I mean, does the 'cryptsetup luksFormat /dev/sdxn' care what type of partition (ext2/3, fat, etc) /dev/sdxn is? You seem to be confusing partitions with filesystems here. cryptsetup works on raw partitions - the filesystems go on top of the encrypted volume: /dev/sdxn - luks volume - filesystem I know that the filesystems go on top of the encrypted volume. All that I want to confirm is whether disk encryption access the partition directly, as you put, works on raw partitions. E.g., if I use partition tool to set partition type to FAT32, what would happen? I'm not certain, but I'm pretty sure that cryptsetup won't care what type the partition is marked as. I'm no expert, but IIUC, those types are just labels, a couple of bytes long, that tell the OS what to expect on the partition, but I don't think it'll make much of a difference when using cryptsetup. I may be wrong, though. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110127162604.2e999d73.cele...@gmail.com
Re: Linux disk partition encryption
T o n g schreef: Hi, I'm thinking to do the disk partition encryptions now. However Hard drive encryption sounds like an intimating concept, mostly because it is. The thought of taking your precious files, then using a mathematical formula to convert them into random noise before scattering them back across your disk is a hard sell. [1] There is no such thing as random noise generated from mathematical formulas. But I do of course understand your issues. I have a more pragmatic view: if you know the algorithm and password, you'll be fine, so keep that secure. Here are my questions, - First very noob question, I don't want whole disk encryption, just want to encrypt some selected already partitioned partitions. If someone mount those encrypted partitions, will they shows up as empty or, there are some hints that the partitions have been encrypted? Truecrypt seems to support hidden partitions, that show up as empty space. As far as I know the luks-dmcrypt setup that I'm advertising does not have that option. - The Ubuntu [3] and CentOS [4] seems to endorse dm-crypt, instead of (widely-used?) cryptsetup-luks. So I need a bit of explanation which is better than others. http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian I have a luks-encrypted external hard drive partition, which is great. When I plug in the disk under kde it will automatically ask for the password. - In terms of encryption used, TrueCrypt supports the following encryption algorithms: AES, Serpent, Twofish, AES-Twofish, AES-Twofish- Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent; And these hash algorithms: RIPEMD-160, SHA-512 Whirlpool [5] Good question. I think for keeping your files safe from the kid-next-door, they'll all be fine. For more serious encryption, they'll probably also be fine. - Is your partition encryption choice as cross-platform as TrueCrypt? No, luks and dm-crypt are linux only - If I put the encrypted partitions in fstab, then I have to enter passphrase for each one of them when PC boot up, I guess. Will the whole boot up be hold up waiting for encrypted partitions passphrases? There's such a thing as the crypttab for automatically decrypting during the boot cycle. I have no experience, though. Another, long explanation of dm-crypt with luks: https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS_for_dm-crypt - how passphrase are cached? Do I have to repeatedly typing in passphrase each time I do the mount? I also heard of passphrase-less disk encryptions. Hmm... I don't want to go there so maybe I can skip that. It is cached until you close the encrypted volume. For proper encryption, you therefore need to go for at least an encrypted swap page, and secure your RAM-memory for something like 30 minutes after switching off power so than nobody can get the password from there. I hope my comments were of some help, others may know more about this. signature.asc Description: OpenPGP digital signature
Re: Linux disk partition encryption
On Wed, 26 Jan 2011 05:36:22 + (UTC) T o n g mlist4sunt...@yahoo.com wrote: ... 2. http://www.tldp.org/HOWTO/html_single/Disk-Encryption-HOWTO/ also, Linux Encryption HOWTO http://encryptionhowto.sourceforge.net/Encryption-HOWTO.html v0.2.2, 04 October 2000 Here are my questions, - First very noob question, I don't want whole disk encryption, just want to encrypt some selected already partitioned partitions. If someone mount those encrypted partitions, will they shows up as empty or, there are some hints that the partitions have been encrypted? A partition cannot be mounted; filesystems can. If the partition is encrypted, no filesystem will be visible. If you mean to ask whether someone analyzing the disk will be able to detect an encrypted datastore, in general the answer is probably yes. There may be some methods to prevent that, but I'm unfamiliar with them. - The Ubuntu [3] and CentOS [4] seems to endorse dm-crypt, instead of (widely-used?) cryptsetup-luks. So I need a bit of explanation which is better than others. Don't understand this. In Debian, there's cryptsetup, which includes LUKS support (cryptsetup-luks is a virtual package satisfied (only) by cryptsetup). From the cryptsetup README.Debian: Cryptsetup is a command-line interface for configuring encrypted block devices via dm-crypt, a kernel device-mapper target. 3. http://www.humboldt.edu/its/security-encryption-linuxubuntu 4. http://beginlinux.com/blog/2009/04/centos-53-encrypted-block-devices/ - In terms of encryption used, TrueCrypt supports the following encryption algorithms: AES, Serpent, Twofish, AES-Twofish, AES-Twofish- Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent; And these hash algorithms: RIPEMD-160, SHA-512 Whirlpool [5] 5. http://www.informit.com/articles/article.aspx?p=1276279 So I need a bit of explanation why your chosen algorithm is better than others. Very very brief will do. [Rough, brief explanation - may not be totally accurate.] AES is both a standards process, as well as a method chosen by that process. AES was the winner of that process; some of the others on your list were finalists. AES has the advantage of having been extensively tested, in both labs and the real world, but some of the others (e.g., Twofish) are supposed to be quite good. Further reading: http://www.schneier.com/paper-aes-comparison.html http://en.wikipedia.org/wiki/Advanced_Encryption_Standard_process http://en.wikipedia.org/wiki/Advanced_Encryption_Standard http://www.brighthub.com/computing/smb-security/articles/53270.aspx http://en.wikipedia.org/wiki/Twofish http://www.schneier.com/twofish.html http://www.image-in.co.il/HTML/SEC4NET/aes_history.html - Is your partition encryption choice as cross-platform as TrueCrypt? No idea, but LUKS / dm-crypt can apparently be used on Windows with FreeOTFE: This software is compatible with Linux encrypted volumes (e.g. LUKS, cryptoloop, dm-crypt), allowing data encrypted under Linux to be read (and written) freely. It was the first open source transparent disk encryption system to support Windows Vista and PDAs. http://en.wikipedia.org/wiki/FreeOTFE - If I put the encrypted partitions in fstab, then I have to enter passphrase for each one of them when PC boot up, I guess. Will the whole boot up be hold up waiting for encrypted partitions passphrases? This obviously depends what's on the partitions you encrypt. - Since I need to encrypt more than one selected partitions, if I want to mount encrypted partitions manually, is there any alternative way than to typing in passphrase for each one of them when mounting them? Yes - use keyfiles, and have the system use them to unlock partitions. You can / should encrypt the keyfile, or put it on an encrypted disk which requires a passphrase. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126092929.adc7f6c8.cele...@gmail.com
Re: Linux disk partition encryption
On Wed, 26 Jan 2011 10:26:16 +0100 Sjoerd Hardeman sjo...@lorentz.leidenuniv.nl wrote: ... No, luks and dm-crypt are linux only There's purportedly Windows support for LUKS / dm-crypt volumes with FreeOTFE: http://en.wikipedia.org/wiki/FreeOTFE Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126093112.212006c8.cele...@gmail.com
Re: Linux disk partition encryption
Hopefully your questions have been answered. I used cryptsetup and LUKS for 2 partitions. I have never had exactly 0 problems with it. LUKS support for multiple passwords has been helpful. Now I don't remember that you actually requested a HOWTO, but here it is anyway. It is easy, just: 1. Create/choose partition 2. cryptsetup luksFormat /dev/sdxn (Give it a passphrase and verify) 3. cryptsetup luksOpen /dev/sdxn name (give it the passphrase) 4. mkfs /dev/mapper/name 5. Add a line to /etc/crypttab 6. Add a line to /etc/fstab 7. mount /dev/mapper/name /mnt/point Now everything should be operational and should show up the same way on a reboot (will ask you for the passphrase). signature.asc Description: Digital signature
Re: Linux disk partition encryption
On Wed, 26 Jan 2011 14:13:09 -0600 green greenfreedo...@gmail.com wrote: Hopefully your questions have been answered. I used cryptsetup and LUKS for 2 partitions. I have never had exactly 0 problems with it. LUKS support for multiple passwords has been helpful. I've had several problems: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541835 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=524485 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588697 That first one was a real head-scratcher, causing a fair amount of time and aggravation. It baffled the the Debian maintainer, as well as kernel devs, for a while. Now I don't remember that you actually requested a HOWTO, but here it is anyway. It is easy, just: 1. Create/choose partition It is often suggested to first write random data to the partition, to make attacks more difficult, e.g.: http://www.hermann-uwe.de/blog/howto-disk-encryption-with-dm-crypt-luks-and-debian 2. cryptsetup luksFormat /dev/sdxn (Give it a passphrase and verify) 3. cryptsetup luksOpen /dev/sdxn name (give it the passphrase) 4. mkfs /dev/mapper/name 5. Add a line to /etc/crypttab 6. Add a line to /etc/fstab 7. mount /dev/mapper/name /mnt/point Now everything should be operational and should show up the same way on a reboot (will ask you for the passphrase). You can also look into using keyfiles, as I mentioned in another message in this thread. Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126153524.c718f9ec.cele...@gmail.com
Re: Linux disk partition encryption
On Wed, Jan 26, 2011 at 9:29 AM, Celejar cele...@gmail.com wrote: A partition cannot be mounted; filesystems can. If the partition is encrypted, no filesystem will be visible. If you mean to ask whether someone analyzing the disk will be able to detect an encrypted datastore, in general the answer is probably yes. There may be some methods to prevent that, but I'm unfamiliar with them. Basically, the primary way to slow down this analysis is to write random data to the entire hard drive. This is how the full-disk LUKS encryption works from the installer. Obviously, since the OP is only wanting to encrypt certain directories, this has limited utility. However, IMHO, if you are considering building or rebuilding a machine, you should consider using the full-disk LUKS encryption. I have been using it for years on a number of machines in a variety of settings. In fact, in my last job, it was required for laptops that their drives be encrypted (it was mainly a Mac/Windows shop), so we Linux admins used LUKS, and as a further step, I put /boot (the only partition that cannot be encrypted) on a USB stick, so that if anyone got the laptop, they had no access to the data. The way I set it up is as follows: Hard drive -- /boot partition -- encrypted swap partition (filled w/random data) -- rest of disk for encryption (filled w/random data) -- LVM -- filesystems As you can see, the LVM and filesystems are within the encrypted portion of the disk. On boot, I am prompted for my passphrase, and once I give it, the filesystems are made available and booting continues. It is possible to place key files on other media and be able to, for instance, boot from a USB key or even boot one encrypted partition from a key file on another encrypted partition. I have done this before, as I have not been able to figure out how to get one encrypted partition to traverse multiple drives.) An additional benefit is that having a key file on another encrypted partiton means that you only have to unlock one partition with a passphrase. The rest will be decrypted automatically. Further reading (Ubuntu has some really good docs on this): https://help.ubuntu.com/community/EncryptedFilesystemHowto http://main.uab.edu/Sites/it/faqs/63837/ There are a number of other Ubuntu EncryptedFilesystemHowto docs, ranging in age from 6.06 to present. Search on help.ubuntu.com... --b -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/AANLkTikyHiEaTunK3qEFzG=egvinnbugxnbwp1r8_...@mail.gmail.com
Re: Linux disk partition encryption
[Please don't cc me on replies.] On Wed, 26 Jan 2011 15:48:15 -0500 Brad Alexander stor...@gmail.com wrote: ... Linux admins used LUKS, and as a further step, I put /boot (the only partition that cannot be encrypted) on a USB stick, so that if anyone got the laptop, they had no access to the data. Why does putting /boot on a USB stick gain you anything? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126160149.39fd71f2.cele...@gmail.com
Re: Linux disk partition encryption
Because if your laptop gets stolen, the odds are that they will not get the USB drive. Thus, it is another layer of security. Plus, if they have /boot, they will be prompted for the passphrase, which means they can brute force it. If /boot is missing, then all they get is a grub message saying Grub error 11. I admit that most people stealing a laptop are more interested in the hardware than the data, and that unless you are running a custom kernel, it wouldn't be rocket science to generate a new /boot, but again, it is another layer and would probably dissuade the script kiddy. --b On Wed, Jan 26, 2011 at 4:01 PM, Celejar cele...@gmail.com wrote: [Please don't cc me on replies.] On Wed, 26 Jan 2011 15:48:15 -0500 Brad Alexander stor...@gmail.com wrote: ... Linux admins used LUKS, and as a further step, I put /boot (the only partition that cannot be encrypted) on a USB stick, so that if anyone got the laptop, they had no access to the data. Why does putting /boot on a USB stick gain you anything? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinofcwvlvy1yn4jdxtjvuynhvop4zysy6n74...@mail.gmail.com
Re: Linux disk partition encryption
On Wed, 26 Jan 2011 16:21:41 -0500 Brad Alexander stor...@gmail.com wrote: Because if your laptop gets stolen, the odds are that they will not get the USB drive. Thus, it is another layer of security. Plus, if they have /boot, they will be prompted for the passphrase, which means they can brute force it. If /boot is missing, then all they get is a grub message saying Grub error 11. I admit that most people stealing a laptop are more interested in the hardware than the data, and that unless you are running a custom kernel, it wouldn't be rocket science to generate a new /boot, but again, it is another layer and would probably dissuade the script kiddy. What I meant was just that it's trivial to write a /boot, so there's no real security gain. --b On Wed, Jan 26, 2011 at 4:01 PM, Celejar cele...@gmail.com wrote: [Please don't cc me on replies.] On Wed, 26 Jan 2011 15:48:15 -0500 Brad Alexander stor...@gmail.com wrote: ... Linux admins used LUKS, and as a further step, I put /boot (the only partition that cannot be encrypted) on a USB stick, so that if anyone got the laptop, they had no access to the data. Why does putting /boot on a USB stick gain you anything? Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/aanlktinofcwvlvy1yn4jdxtjvuynhvop4zysy6n74...@mail.gmail.com Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126165646.1be97ecc.cele...@gmail.com
Re: Linux disk partition encryption
Celejar: Brad Alexander stor...@gmail.com wrote: Linux admins used LUKS, and as a further step, I put /boot (the only partition that cannot be encrypted) on a USB stick, so that if anyone got the laptop, they had no access to the data. Why does putting /boot on a USB stick gain you anything? Because an unencrypted /boot may be altered by an attacker without you noticing it. Theoretically, the kernel may be replaced by another one that reports your passphrase to the attacker. J. -- I feel yawning hollowness whilst talking to people at parties. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Linux disk partition encryption
On Wed, 26 Jan 2011 23:24:07 +0100 Jochen Schulz m...@well-adjusted.de wrote: Celejar: Brad Alexander stor...@gmail.com wrote: Linux admins used LUKS, and as a further step, I put /boot (the only partition that cannot be encrypted) on a USB stick, so that if anyone got the laptop, they had no access to the data. Why does putting /boot on a USB stick gain you anything? Because an unencrypted /boot may be altered by an attacker without you noticing it. Theoretically, the kernel may be replaced by another one that reports your passphrase to the attacker. Oh, basically the Evil Maid attack. Fair enough. But then you have to make sure the attacker can't flash the BIOS ... Celejar -- foffl.sourceforge.net - Feeds OFFLine, an offline RSS/Atom aggregator mailmin.sourceforge.net - remote access via secure (OpenPGP) email ssuds.sourceforge.net - A Simple Sudoku Solver and Generator -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110126174600.a8866289.cele...@gmail.com
Re: Linux disk partition encryption
On the 26/01/2011 06:36, T o n g wrote: Hi, I'm thinking to do the disk partition encryptions now. However Hard drive encryption sounds like an intimating concept, mostly because it is. The thought of taking your precious files, then using a mathematical formula to convert them into random noise before scattering them back across your disk is a hard sell. [1] 1. http://www.maximumpc.com/article/howtos/ how_to_encrypt_your_entire_hard_drive_for_free_using_true_crypt So I need some demystify of the whole thing around disk/partition encryption [...] Can't comment on the crypto science, but I am using it and it works just fine, both full disk (cryptsetup LUKS on raid and usb sticks) and for files (ecryptfs). Here are my questions, - First very noob question, I don't want whole disk encryption, just want to encrypt some selected already partitioned partitions. If someone mount those encrypted partitions, will they shows up as empty or, there are some hints that the partitions have been encrypted? Don't know what you mean exactly by show up as empty, with ecryptfs the mountpoint will indeed be empty unless the crypted directory is open. But it's always possible to guess that encryption is being used, or guess it from missing space on the hard drive. - The Ubuntu [3] and CentOS [4] seems to endorse dm-crypt, instead of (widely-used?) cryptsetup-luks. So I need a bit of explanation which is better than others. 3. http://www.humboldt.edu/its/security-encryption-linuxubuntu 4. http://beginlinux.com/blog/2009/04/centos-53-encrypted-block-devices/ Using cryptsetup and doing good. cryptsetup (LUKS) is using dm_crypt. The old alternative (and insecure) way was cryptoloop. - In terms of encryption used, TrueCrypt supports the following encryption algorithms: AES, Serpent, Twofish, AES-Twofish, AES-Twofish- Serpent, Serpent-AES, Serpent-Twofish-AES, Twofish-Serpent; And these hash algorithms: RIPEMD-160, SHA-512 Whirlpool [5] 5. http://www.informit.com/articles/article.aspx?p=1276279 So I need a bit of explanation why your chosen algorithm is better than others. Very very brief will do. Used standard aes (256), serpent and twofish, settled with twofish since it seems really solid, standard enough, and didn't show any speed hit with my workload. More specifically lately I used twofish-cbc-essiv:sha256 with a keysize of 256. I believe unless I am nominated as public enemy my data are safe from the average lone cracker, and most probably even the serious ones. - Is your partition encryption choice as cross-platform as TrueCrypt? I don't care about cross-platform, can't comment. For me if it works on any linux flavours it's good enough, I will always be able to retrieve my data. - If I put the encrypted partitions in fstab, then I have to enter passphrase for each one of them when PC boot up, I guess. Will the whole boot up be hold up waiting for encrypted partitions passphrases? Yes, unless you do as mentioned below. Yes the boot process will wait for you to type in the passphrases, or will look for the keyfiles. - Since I need to encrypt more than one selected partitions, if I want to mount encrypted partitions manually, is there any alternative way than to typing in passphrase for each one of them when mounting them? You can chain the mounting by using a passphrase or keyfile for the first, and then store keyfiles for the subsequent in keyfiles on the first encrypted partition to be mounted (unsafe, maybe just for swap ?), or all the keyfiles on a usb stick. This is less secure since if the system is compromised the keyfiles could be stolen, but using a usb stick only when mounting is needed reduces the risk. I never tried but maybe pam could be used for this ? For swap I resorted to use (clear) swap file on encrypted partitions (could be /, /home or any as long as it's mounted at boot time), it's more flexible and works as good as a dedicated partition for me, but my systems have plenty of ram with reduced swappiness and I rarely see swapping. - how passphrase are cached? Do I have to repeatedly typing in passphrase each time I do the mount? I also heard of passphrase-less disk encryptions. Hmm... I don't want to go there so maybe I can skip that. I don't think caching the passphrases anywhere would be secure, when the volume is in use it is in clear (as opposed to encrypted), so is the swap and ram, caching would not be safe. Maybe some keyring daemon can take care of that, but then your passphrases are only as safe as the one of the keyring. BTW, I just need a mini intro about disk encryption, it does not need to be in-depth or comprehensive but rather short and to the point. Thanks a lot. I used the man and: General: https://secure.wikimedia.org/wikipedia/en/wiki/Disk_encryption_theory#XTS https://secure.wikimedia.org/wikipedia/en/wiki/Full_disk_encryption http://clemens.endorphin.org/cryptography
Re: Linux disk partition encryption
Celejar: Jochen Schulz m...@well-adjusted.de wrote: Celejar: Why does putting /boot on a USB stick gain you anything? Because an unencrypted /boot may be altered by an attacker without you noticing it. Theoretically, the kernel may be replaced by another one that reports your passphrase to the attacker. Oh, basically the Evil Maid attack. Fair enough. But then you have to make sure the attacker can't flash the BIOS ... Exactly. I didn't remember there was a name for this attack. J. -- There is no justice in road accidents. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
