bjoernvold.com

Greetings Earthlings,

I want to encrypt everything on my Debian box, and although there are plenty of howto's on doing this, I haven't seen a single howto that explains why to do any of the steps outlined in the instructions. In short, I have a Debian Wheezy box that has an 80GB drive where I plan to have the OS and swap, and I have a 1TB drive where I plan to store my data. I would like both drives fully encrypted and would like one password for both but would settle for two passwords if need be. However, while setting this up I would like to know the answers to questions like:

1. Is there something better than dmcrypt/LUKS that I should use?
2. What cyphers are not available to me and why not?
3. What cyphers are available to me, which should I use, and why?
4. What hashing systems are not available and why?
5. What hashing systems are available, which should I use, and why?
6. Should I be concerned about entropy generation and if so then how do I manage it?

I would also be interested in understanding the hierarchy of the design, and how to control it. For example, my understanding of a dmcrypt/LUKS design is that it begins with an empty physical disk, creates a group via LVM, encrypts that group, creates partitions within that encrypted group, lays file systems on the partitions, and then finally files are put on the file system. But are those assumptions correct? And can I name the group something more meaningful? Can I name the group something more meaningful during OS install? Why is it that if I take a dmcrypt/LUKS drive out and put it in another PC, I can see a list of partitions on the drive? Shouldn't that information be completely inaccessible to the new host because the partitions should all be in an encrypted LVM group?

It just feels to me like there is a lot of stuff that just "happens magically in the background" rather than being controlled specifically by me. Am I just being paranoid and I should just trust that these questions don't need to be asked? Am I way off base here?

S.

Ok Ill have to start somewhere but don't expect an answer to all questions in the first post.
Dmcrypt is the crypt system of the Linux kernel version 2.6 and later so it uses the cryptographic routines from the kernel's Crypto API.
This is a cryptographic framework in the kernel.

That kind of makes it a sensible standard. You can do a lot with it but the operations can be pretty complex so I guess that is why you are offered the "click and install" options.

This makes sense because very few would use it if they had to do it all manually.

If you need control and want to know what is done you can use the cryptsetup command.
From the Arch Wiki:

This section covers how to manually utilize dm-crypt to encrypt a system through the cryptsetup command. It covers examples of the Encryption options with dm-crypt, deals with the creation of keyfiles, LUKS specific commands for key management as well as for Backup and restore.

So the cryptsetup command line tool is they key for paranoid control.
Again I cannot say it better than the Arch Wiki:

Cryptsetup is the command line tool to interface with dm-crypt for creating, accessing and managing encrypted devices. The tool was later expanded to support different encryption types that rely on the Linux kernel device-mapper and the cryptographic modules. The most notable expansion was for the Linux Unified Key Setup (LUKS) extension, which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use. Devices accessed via the device-mapper are called blockdevices. For further information see Disk encryption#Block device encryption.

I am not saying you should use Arch - but the documentation in the Arch Wiki is the best IMO.

And To answer Your am I paranoid question:
No you are not paranoid

The good news is that the NSA has flagged what they can crack and thereby also what they cannot

They pressured the Tech companies to go for 128 AES keysize. They preferred 128 so naturally that they can crack.
It is not clear if they can crack 256 - but that will be hard.

Since the NSA wrote most of the Hash algorithms there is every reason to be paranoid - given the recent history and the NSA's ambitions to control the entire electronic world.

On the other hand; they made it for themselves too and they want something secure.
The version SHA3 is not written by NSA and has a different approach than SHA0,1 and 2.

This version seems to be good if you want to keep Big Brother of your back.
SHA1 is considered adequate as of January 2014 though.

The attack on LUKS are done via the unencrypted boot processes.
The scenario is that some software has to ask for the user passphrase and this software cannot be encrypted because it must run before the encryption is started.

For Linux encrypted with LUKS that is typically the bootloader and the partition /boot

This enables an attack that logs the key and sends it to an attacker or installs a rootkit.
This attack is known as the evil maid attack and has been demonstrated against Truecrypt.

To avoid this you can boot the system from an USB stick containing the components required to boot the encrypted system on the harddisk.

You can then remove the USB stick (and hide it ) on a running system leaving the attackers with only an encrypted root file system.

If the attacker should gain access they can destroy data then - but not manipulate it.

This leaves the attack via manipulated hardware in the shape of keyloggers and reflashing of BIOS.

Since most of the computers are sold with this type of manipulation (educated speculation based on the NSA actions - and documented cases -so far): the NSA and (at least) all the "Five Eyes" would still have access.

Because they will be able to log the passphrase.



It is hard to say what Intel has been instructed to put in their hardware but it would be utterly naive to think that the NSA has never contacted Intel.

The question is only if it is targeted or if every computer is manipulated.

So the absolute safe computer (If there is such a thing these days) would be an older computer ("pre NSA manipulation age") with full dm-crypt encryption and "floppydisk" or USB boot.

viking60 wrote:So the cryptsetup command line tool is they key for paranoid control.

Hmmm, so would it be possible to have my boot drive manually configured by cryptsetup? Could I perhaps setup a drive/volumes/groups/partitions ahead of time, boot the Wheezy installer media, manually decrypt the volume groups, then run the installer? Or is there really no reason to do so?

viking60 wrote:To avoid this you can boot the system from an USB stick containing the components required to boot the encrypted system on the harddisk.

You can then remove the USB stick (and hide it ) on a running system leaving the attackers with only an encrypted root file system.

Well I don't really have much choice with this one since the computers (two of them anyways) are 30km from here. I am not very worried about an Evil Maid attack though since it requires the password to be entered after someone has had physical access to the machine, which I believe I would notice.

I am going to go fiddle with trying to use cryptsetup to manually configure a boot drive... thanks!

S.

Snorkasaurus wrote:Hmmm, so would it be possible to have my boot drive manually configured by cryptsetup? Could I perhaps setup a drive/volumes/groups/partitions ahead of time, boot the Wheezy installer media, manually decrypt the volume groups, then run the installer? Or is there really no reason to do so?

The /boot partition can be installed on the standard vfat partition of a USB stick, if required and yes it can be done manually.
Also remember to do a

If certain AES ciphers excel with a considerable higher throughput, these are probably the ones with hardware support in the CPU. You want to keep the system fast.
Have a look here

viking60 wrote:The /boot partition can be installed on the standard vfat partition of a USB stick, if required and yes it can be done manually.

Well, I can't use a USB stick (or any other removable device) as my boot device because the PC [at least two of the PC's I wish to do this to] is not local to me. I have someone who can type in a password at the remote site, but USB booting is not an option. I also use some older PC's, some of which may not support USB booting.

S.

Turns out Wheezy comes with cryptsetup v1.4.3 which unfortunately does not include the "benchmark" command line option.
S.

Ah OK I guess the Debian people have found an optimal solution.
The Arch Wiki is a" do it yourself" wiki.

viking60 wrote:Ah OK I guess the Debian people have found an optimal solution.
The Arch Wiki is a" do it yourself" wiki.

Well that is the problem... I am looking for compelling evidence that the encryption related choices Debian has made are the best for me and if not, a description of how to get Debian running on a custom rolled encryption design.
S.

I Guess you can still use cryptsetup. You are not required to run benchmark.
Since you are running an Older Debian version without systemd you will be some years behind the Arch documentation.

You will find cryptsetup in the wheezy-backports You can add that repo in /etc/apt/sources.list.

You should still be able to control the process then.
1

2
Overwrite the disk with random data

3

This encrypts your partition with 256-bit AES XTS algorithm - not cracked by NSA so far - in fact 128bit has not been really cracked either because the theoretical crack demands more data than everything on all the computers on the planet today. AES is pretty secure

Furthermore you will be prompted for a passphrase - use sentences and slang like "Aint to Happy'boutNSAtheseDays2015" (use another language than english like Eskimo language etc) this will be the weak point of the encryption so make it long and hard.

4
Name the partition (Naturally - Berserk would be the logical name )

Now your encrypted partition is available to your system as /dev/mapper/berserk.
5
Make a filesystem and Label it (I have labeled it Berserk of course)

ext4 is the filesystem here.
6
Time to mount the partitions


Now you have an encrypted partition available on /media/berserk where you can add your private stuff.
7
To unmount the partition:


It will be depending on your DE if the encrypted disk is automatically mounted - but it probably will be.

To encrypt swap (Swap has been used for cross site scripting attacks ):

You can check where your swap is with:


That might work

The good news is that all that stuff should work just fine... the bad news is, it doesn't do what I am looking for which is to encrypt Wheezy itself. Of course I do want my data to be encrypted, but I also want my OS to be encrypted. I am quite aware of the fact that something has to be unencrypted to boot from, but places like /etc and /var contain plenty of information that I think should be encrypted.

Now I know that it is entirely possible to encrypt Wheezy at install time but it is not possible to customize that encryption at install time. You can't name/label partitions, groups, or volumes and you can't select ciphers, hashes, or entropy (at least not in any way that makes sense to me). There are no explanations about what cypher, hash, or entropy options are available or why anyone would choose one over another. Based on some of what I have read recently I thought that maybe the graphical installer might have more options, and it "kind of" does, but it is a nightmare and is less user friendly than a hammer in the head. My next thought was that perhaps I could setup a drive with the appropriate encrypted partitions, boot from the Wheezy CD, cancel the installer, decrypt the partitions I wish to use, restart the installer, and install on the already en/decrypted partitions... but I had trouble finding anyone else who had done anything like that.

What you get when you use the Wheezy installer to encrypt your system drive is:

But I think that Wheezy's installer makes a confusing mess of partitions, groups, and volumes. And I think that it would be nice to name that map something other than "sda5_crypt". In fact, I see no reason to have to create a logical partition with two of my three system partitions inside it.

Now, when looking at the cipher it seems that AES is fine, but are there alternatives to XTS that I should be considering? And why? The answer found in this post gives me the impression that perhaps I should at least be considering CTR over XTS. And from what I have read, PLAIN is better for me than PLAIN64 because PLAIN64 is intended for drives over 2TB, which I do not have, and PLAIN64 has some apparent vulnerability watermarking compromises.

Looking at the stats of sda5_crypt above, it says that the keysize is 512 bits. Does that mean SHA-512 is being used for the hash? If not, then what is being used for the hash?

I guess what I am getting at is that I know what files I want encrypted, and I know that at least part of my operating system is on the list of what I want encrypted, but I do not want to blindly assume that the makers of Debian (or any other distro for that matter) know what works best for me and just accept the decisions they (or their installer) made for me without questioning it. However, I don't see a way to encrypt my system drive without blindly accepting their decisions.

If aes-xts-plain64 is the best thing for me then I'll use it, but I was hoping to find out why the other options are not the best for me. At a bare minimum it sounds like I should at least be considering aes-ctr-plain in favour of aes-xts-plain64. If it takes longer to setup a PC with a different kind of "better for me" encryption then I'll gladly do it. I just wish I could find a comprehensive list of the options available that clearly explains the advantages and disadvantages of selecting one over another. Hopefully that makes a little more sense.

S.

Snorkasaurus wrote:The good news is that all that stuff should work just fine... the bad news is, it doesn't do what I am looking for which is to encrypt Wheezy itself. Of course I do want my data to be encrypted, but I also want my OS to be encrypted. I am quite aware of the fact that something has to be unencrypted to boot from, but places like /etc and /var contain plenty of information that I think should be encrypted.

What do you mean by Wheezy itself? You can encrypt the disk where "Wheezy itself" is - including /var and /etc
The only thing to leave unencrypted would be /boot

Snorkasaurus wrote:Now I know that it is entirely possible to encrypt Wheezy at install time but it is not possible to customize that encryption at install time. You can't name/label partitions, groups, or volumes and you can't select ciphers, hashes, or entropy (at least not in any way that makes sense to me). There are no explanations about what cypher, hash, or entropy options are available or why anyone would choose one over another. Based on some of what I have read recently I thought that maybe the graphical installer might have more options, and it "kind of" does, but it is a nightmare and is less user friendly than a hammer in the head. My next thought was that perhaps I could setup a drive with the appropriate encrypted partitions, boot from the Wheezy CD, cancel the installer, decrypt the partitions I wish to use, restart the installer, and install on the already en/decrypted partitions... but I had trouble finding anyone else who had done anything like that.

What you get when you use the Wheezy installer to encrypt your system drive is:

Code: Select all

# cryptsetup status sda5_crypt
/dev/mapper/sda5_crypt is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/sda5
  offset:  4096 sectors
  size:    487890944 sectors
  mode:    read/write

But I think that Wheezy's installer makes a confusing mess of partitions, groups, and volumes. And I think that it would be nice to name that map something other than "sda5_crypt". In fact, I see no reason to have to create a logical partition with two of my three system partitions inside it.

Now, when looking at the cipher it seems that AES is fine, but are there alternatives to XTS that I should be considering? And why? The answer found in this post gives me the impression that perhaps I should at least be considering CTR over XTS. And from what I have read, PLAIN is better for me than PLAIN64 because PLAIN64 is intended for drives over 2TB, which I do not have, and PLAIN64 has some apparent vulnerability watermarking compromises.

Looking at the stats of sda5_crypt above, it says that the keysize is 512 bits. Does that mean SHA-512 is being used for the hash? If not, then what is being used for the hash?

It does mean that you are using AES-512

The reason to put several partitons into one big one (LVM) has the following reason: You can resize the partitions later on which is a very good thing.
This entire partition needs a special key phrase to be visible.
LVM will also take care of erasing and overwriting the data (as described howto do manually above)
LVM will also create the unencrypted /boot partition and encrypt the rest aka put it in that big partition containing other partitions.

Snorkasaurus wrote:I guess what I am getting at is that I know what files I want encrypted, and I know that at least part of my operating system is on the list of what I want encrypted, but I do not want to blindly assume that the makers of Debian (or any other distro for that matter) know what works best for me and just accept the decisions they (or their installer) made for me without questioning it. However, I don't see a way to encrypt my system drive without blindly accepting their decisions.

I hope my answers above will contribute to not "blindly accepting" - accepting with open eyes seems to be an acceptable option in the case of Debian though.

Snorkasaurus wrote:
If aes-xts-plain64 is the best thing for me then I'll use it, but I was hoping to find out why the other options are not the best for me. At a bare minimum it sounds like I should at least be considering aes-ctr-plain in favour of aes-xts-plain64. If it takes longer to setup a PC with a different kind of "better for me" encryption then I'll gladly do it. I just wish I could find a comprehensive list of the options available that clearly explains the advantages and disadvantages of selecting one over another. Hopefully that makes a little more sense.

S.

aes-xts-essiv is considered safer (and slower) for the paranoid ones:
I guess you could do something like this:


Somehow I have a feeling that this Help case never can be "solved" though
(100% safe is hard to achieve these days..sadly)

viking60 wrote:What do you mean by Wheezy itself? You can encrypt the disk where "Wheezy itself" is - including /var and /etc
The only thing to leave unencrypted would be /boot

Hmmm, I don't think I am explaining myself very well. To use the Arch docs... I like the way they have described "data encryption" versus "system encryption" here. Based on their description, what I am looking for is "system encryption".

I realize that I am referring to an existing PC... but I am interested in ensuring that I am using the most appropriate encryption and am perfectly willing to rebuild/replace this machine. I think part of the problem in our communication though is that when you are installing Arch you are doing so from (I think) a command line and are using cryptsetup directly to create your encrypted partitions, groups, and volumes. You are also using cryptsetup to choose your cipher and other parameters for your encryption. However, when I am setting up Debian I am looking at this:

And I have fewer options than you do (like not being able to select a cipher, mode, IV, etc.) because you are using cryptsetup directly and I am using the Debian installer. What I am looking for is a way to do "system encryption" of a Debian box with custom selected cipher, hash, groups, volumes, etc. - but I don't see where I can achieve that in the Debian installer. And I am looking for descriptions of the available block ciphers, modes, initialization vectors, hashing, etc. and why to use or not use one versus another. There is a "manual" option when partitioning in the Debian installer, but it is filled with what seems to me to be a ridiculous hierarchy of volumes, groups, partitions, and other complications that I would like to avoid.

viking60 wrote:The reason to put several partitons into one big one (LVM) has the following reason: You can resize the partitions later on which is a very good thing.

Fortunately, I have zero need for this. The machine has a 250G drive which is 4% used and at its current rate should reach 50% usage in about 50 years.

viking60 wrote:This entire partition needs a special key phrase to be visible.

Certainly... I got that.

viking60 wrote:LVM will also take care of erasing and overwriting the data (as described howto do manually above)

I typically DBAN all drives the same day they are removed from any machine (whether they were previously encrypted or not) so I don't need this, but understand exactly why it is done.

viking60 wrote:LVM will also create the unencrypted /boot partition and encrypt the rest aka put it in that big partition containing other partitions.

I thought this was being done by the Debian installer (or manually in your case because you are using Arch)?

viking60 wrote:aes-xts-essiv is considered safer (and slower) for the paranoid ones:
I guess you could do something like this:

Code: Select all

cryptsetup -y --cipher aes-xts-essiv:sha256 --key-size 512 luksFormat /dev/PARTITION

Somehow I have a feeling that this Help case never can be "solved" though

That cryptsetup command looks pretty close to what I am looking for, except I guess I was wondering:

• aes seems nice, but why not blowfish/twofish, and why not serpent?
• xts seems nice, but is it more appropriate than cts? Or are there other modes I should consider?
• essiv sounds better than plain64 (watermarking) and approximately as good as plain, or is that not true? Are there other IV mechanisms I should be considering?
• sha256 makes sense to me since as I understand it, SHA256 is a function of SHA2 which offers significant [collision] advantages over SHA1. What I have read leads me to believe that SHA3 offers no significant advantages over SHA2 - but is there anything I am missing, and is there a more appropriate hashing I should consider?
• Also, can I do away with the volumes and groupings that the Debian installer seems to like so much? Looking at your cryptsetup command above it would appear I can avoid them because you are applying the command to "/dev/PARTITION" rather than a group or volume. But is "drive expansion" the only reason for using groups and volumes, or am I missing something?

Ultimately, I am having a hard time figuring out exactly what encryption components to use and why. And to me the "why" is as important as the "what". Since the Debian installer does not involve using cryptsetup directly, is there a way to pre-create the encrypted partitions/groups/volumes/whatever and then use the Debian installer to install on them? Or perhaps a way to do the install and encrypt afterwards? Or ... well, I am open to ideas.

S.