Re: [solved] Switching to encrypted disk

Owe for sure, rsync is fantastic. Use what you trust.

Tar preserves directory structure, owner & group, and all other meta-data for all files and directories. Tar can also do Incremental backups. You can also list the contents and extract spesific files/directories from a tar backup. You can exclude or include specific files/directories. Even better, you can | pipe the output of tar into gpg to create a tar.gpg encrypted backup. I have recovered my system many, many times with tar backups. That is what tar "Tape ARchive" program is for. Infact, like all Linux distro's packages are basicaly just .tar files. Tar is like the first archive command ever created for UNIX. Tar and rsync are the only archive solutions I trust.

Ya, LVM makes things easier and safer. Without it, if you have multipe encrypted paritions, you ether have to enter the pasword/keyfile for each partition, or put the password/keyfile-location in plain text in the /etc/crypttab file for the rest of the paritions.

Owe, and it turns out my laptop is Sleeping when I close the lid of my laptop. I just didn't realize because my SSD is so fast. Note, I am using pure systemd.

Re: [solved] Switching to encrypted disk

They key is in memory already, so the cold boot attack is a risk anyway. Unless, LUKS obfuscates the key in memory in some way. I am not sure how LUKS handels the key in memory. (LUKS dose all of the key management stuff, and dm-crypt still dose the encryption of the blocks.)

If say, you did not have your /swap parition encrypted then you suspened, or certainly when you hibernate, the key could be swaped out to the non-encrypted /swap.

..Owe, and ya, I always turn off my computer. Just like sometimes in class I'll close the lid, but I'll be sitting infront of it the whole time. I turn it off becuase, ya, until I turn off the comptuer the drive is effectively not encrypted. FDE is a Physical security messure. The online security is where GRsecurity, PaX, and RBAC come in, and AIDE for integrity.

Re: [solved] Switching to encrypted disk

To protect against cold boot attack you can use TRESOR (TRESOR Runs Encryption Securely Outside RAM). It stores the key in the CPU debug registers, so when your computer is shutdown the key disappears.

You can't use suspend with it though if I remember correctly.

You have to patch the kernel for this to work however. I believe there's a package in AUR.

Regarding speed:

WonderWoofy wrote:

I am also curious how much harder it will make your laptop work. I know that you have already been experiencing power regressions and/or heat increases. So what is this extra work going to do with that already occuring.

cfr wrote:

I don't have enough hard drives to do that but thanks anyway. And I don't have an SSD.

I do wonder how much this is going to impact on performance once I find time to set it up but I guess everything has a downside .

This was a minor issue a few years ago, but nowadays when LUKS has multi-threading support you won't notice much difference.

Re: [solved] Switching to encrypted disk

hunterthomson wrote:

They key is in memory already, so the cold boot attack is a risk anyway. Unless, LUKS obfuscates the key in memory in some way. I am not sure how LUKS handels the key in memory. (LUKS dose all of the key management stuff, and dm-crypt still dose the encryption of the blocks.)

If say, you did not have your /swap parition encrypted then you suspened, or certainly when you hibernate, the key could be swaped out to the non-encrypted /swap.

..Owe, and ya, I always turn off my computer. Just like sometimes in class I'll close the lid, but I'll be sitting infront of it the whole time. I turn it off becuase, ya, until I turn off the comptuer the drive is effectively not encrypted. FDE is a Physical security messure. The online security is where GRsecurity, PaX, and RBAC come in, and AIDE for integrity.

Guess I should say it makes you more vulnerable. If you suspend your laptop and someone manages to steal it, they can take their time setting everything up before they attempt to retrieve the key. If you power it off, they will need to be able to steal it right after you power it down and immediately attempt to retrieve the key or preserve the RAM sticks, which is much less likely.

Fairly unlikely that your average Joe would know how to do this though. Would have to be a targeted attack by a very knowledgable individual, so you can balance risk vs. reward here.

Re: [solved] Switching to encrypted disk

Isola wrote:

To protect against cold boot attack you can use TRESOR (TRESOR Runs Encryption Securely Outside RAM). It stores the key in the CPU debug registers, so when your computer is shutdown the key disappears.

@Isola: TRESOR is pretty interesting. Without wanting to highjack cfr's thread with too much non-KISS .. I read about it, have you actually used it? If yes, have you tried performance of it? They write that on a pre-AES NI processor (like yours from 2008, or mine from this year ..), the crypto takes 6x that much processor power.

Re: [solved] Switching to encrypted disk

Maybe I should make clear that I doubt that MI5, the CIA, international gangsters or similarly well-resourced parties have much interest in the contents of my laptop and I'm not really worried about attacks which would require a great deal of motivation and effort to pursue. Of course, I could be wrong but as far as I know there's nothing *that* interesting on my machine!

I'm mostly concerned about the kind of attack where the fact that it is my laptop in particular is mostly irrelevant.

Re: [solved] Switching to encrypted disk

You forgot to mention MI6, they seem to become pretty active these days again

But yes: Back to your thread and question regarding performance. I wanted to add to the others already answering on it that. I doubt that you will notice _any_ difference. Objective benchmarks are difficult always I find.If you are interested in a benchmark-test in particular, feel free to propose it. I am sure someone will do it for you (if it does not involve downloading one of those huge benchmark ISOs..).

Still, the best way would to test it yourself. All you need is a bit space on your harddrive, setup a separate LUKS partition there as a separate mount and test it! Map your browser cache into it and /tmp, or whatever you feel useful to test it with.

Re: [solved] Switching to encrypted disk

Yes, but MI5 is concerned with internal threats. (Which is why the government denied its existence for so long - they were happy to admit they spied on "foreigners". So MI6 officially existed but MI5 did not.) So MI5 would be more likely to come after me. (Though I find it hard to believe it would be worth their while unless they are interested in moral philosophy which seems unlikely given their track record.)

Re: [solved] Switching to encrypted disk

Re: [solved] Switching to encrypted disk

...he, he, he,

Ya, it is vary easy to get carried away when one starts to secure one's self. Sure, nothing is 100% secure, but you can raise the bar significantly. At least now, it will take some real effort and planing for someone to steal your laptop expecting to get the data on it. Without FDE, just anybody could get it.

Boy, as scarry as it is. The NSA, CIA, MI5, ABC... really are real threats to everyone these days. However, unless you stand out, you will only be under dragnet surveillance. In which case, grsecurity, tor, FDE, noscript/adblock-pluss/https-everywhere.. and stuff will still protect you quite a lot.

Re: [solved] Switching to encrypted disk

cfr wrote:

Yes, but MI5 is concerned with internal threats. (Which is why the government denied its existence for so long - they were happy to admit they spied on "foreigners". So MI6 officially existed but MI5 did not.) So MI5 would be more likely to come after me. (Though I find it hard to believe it would be worth their while unless they are interested in moral philosophy which seems unlikely given their track record.)

You are right, of course, which is why I don't bother to patch my kernel with TRESOR and don't lose any sleep over it. Still is nice to know what is possible at least.

WonderWoofy wrote:

Well, in the US, we just let them all do it in the effort to thwart terrorism! It is sad really.

I can't vouch for what it claims, and haven't seen anything yet to back it up (the NSA denied the report's claims during a congressional hearing), but it's still an interesting read. We are getting very much off-topic here, though.

Re: [solved] Switching to encrypted disk

Pres, the NSA said "They" do not track all Amaricans communications. This is true, however, the NSA just asks AT&T, Verison, Google, Comcast... to give them the records they keep on all Amaricans. Basically, the congressional hearing was asking the wrong questions.

Re: [solved] Switching to encrypted disk

edit: redacted by myself as it was off-topic (see below). With in above post I actually tried to hint to a long-delayed but now upcoming movie sequels' release, which was of course confusing and utterly off-topic also. Have a nice day.

Re: [solved] Switching to encrypted disk

Actually, I think this thread is about moving to encryption in general. The OP (cfr) stated earlier that he actually does not have an FDE capable disk, so the discussion is regarding the alternatives he might be able to take.

Re: [solved] Switching to encrypted disk

@WonderWoofy: Just to clarify .. as I see the terminology also, FDE as "full-disk-encryption" encompasses all methods discussed in the thread, including the self-encrypting drives (SED, i.ie. HDD/SSD with hardware encryption via the controller).

Re: [solved] Switching to encrypted disk

Strike0, I see. I just assumed that since, what you are telling me is called SED, hardware vendors label FDE drives, that it was the correct term for it. Though admittedly, it would not be the first time hardware vendors did stupid crap. Also because many of these methods involve encrypting most of the disk, but not the bootable portions and/or partition mapping, it would not be called full disk encryption.

Re: [solved] Switching to encrypted disk

Yes, I have read hardware vendors use both terms for hardware based encryption also, which is fine really in my view if you see SED as subset of FDE. And of course you are right FDE is a misleading term, if parts of the disk (i.e. /boot essentially) have to be left unencrypted - which really is due to legacy BIOS/MBR definitions. That ambiguity also is described in the wikipedia introduction:

Re: [solved] Switching to encrypted disk

from one of Arch's earlier install USB keys (September? October? kernel is 3.5.3).

Arch oopsed the first time I booted with the key but seems to have settled down now.

I'm still not entirely sure what I'm doing next with it. I still haven't quite got the advantages of LVM.

That is, I understand the benefits if you have more than one disk and want to use them as one or use parts of them as one. But that's not the case for me. However, I believe that there are advantages even with one disk.

Is one advantage that if I put LVM at the bottom and then layer dm-encrypt + LUKS on top I'm encrypting the LVM bit. I can then put regular looking partitions on top of all of that? So if there's just one encrypted partition at the bottom (in addition to unencrypted /boot and /boot/efi), the system should only need one password entered on boot without the need to save it in any form to disk?

Whereas if I have regular partitions underneath dm-crypt + LUKS, each one will need a password entered (or the password saved somewhere on disk albeit in encrypted form)? Fedora sometimes asks for my password for every partition and I wonder if this is why (though it doesn't always do it which seems odd).

Note: I know that I could avoid unencrypted partitions altogether but I do not want to do that. Frankly, I'm more afraid that I'll lose or destroy the USB key than that somebody will read my data. My paranoia about security/privacy is nothing in comparison to my paranoia about losing data...

Re: [solved] Switching to encrypted disk

For each "cryptsetup luksFormat" you run during partitioning you have to key in a safe passphrase and you will have to re-enter that each time you cold-boot. The only exception is a separate swap partition which can have a random password.

I omit LVM volume groups in the examples, since they dont matter for your laptop setup. Also the option of using key-files is not considered.

Re: [solved] Switching to encrypted disk

Hey cfr, you are actually doing this? Glad to see you have finally found the time, since I know you have been exploring the idea for quite some time. Personally, I would go with 1b from above. I like the idea of not only having to put in one password, but also that the entire logical volume layout is hidden until you the key is entered. It seems like a nice balance between simplicity/convenience and functionality.

If you don't encrypt at least /home /tmp /var swap you will probably be leaking data to non-encrypted partitions, and if you go this far there probaly is not any more of a performance hit just encrypting all of it.

Because your i3-2367M dose not support AES-NI you should go with TwoFish for symmetrical encryption, and SHA-512 for the hash.

Sure, if you are concerned about security, it could be argued that your time may be better spent learning how to use linux-grsec from the AUR. I've submitted default config requests and the maintainer now basically ships with my settings. The only change I make is I turn Off sysctl support, and change the group # for /proc access so it is different from the TPE trusted group. That way I can have a user be able to run code in a directory owned by the user but still not be able to access /sys nor /proc.

In any case, the argument for disk encryption on mobile devices is, “Do you trust laptop thieves with all your data?”

I admit, 25% of the reason I bought this new laptop was because it has AES-NI. This way I can do Full-disk encryption with no overhead on my SSD. So, full-disk-encryption + no-overhead = no-brainer. However, before I got this I spent my time on OS security. Then spent loads of time Symlinking dir's to my encrypted SD Card and /tmp which is mounted in a tmpfs, to avoid leaking data.