to encrypt or not to encrypt a secondary disk
 

I am running Slackware64 14.1 and I have a secondary 500GB hard disk on my desktop system. I am considering options to add encryption, such as encrypt that whole disk or maybe instead put MariaDB files on that drive and storing sensitive data in the DB, encrypting just those entries. Does anyone have experience with encryption on Slackware? Can you give me some pros and cons of encrypting a drive versus maybe putting private data on a thumb drive or other options?

The easiest thing is to encrypt the whole drive. I can't think of any disadvantage to encryption and it is so easy to set up. If you put your data on a thumb drive then encryption is more important.

Brian

Full disk encryption is safer, that way there is no chance of unencrypted files hitting the disk.

There are disadvantages to encryption. You could lose the key. It is somewhat harder to recover data in case of failure. If you don't also apply some steganography it will also raise suspicion.

I cannot recommend using a USB stick as a sole backup method, they fail quickly and unexpectedly.

And USB sticks can be hacked at the firmware level.

I sounds good but I have some questions. First, can you point me to docs that will explain how to set up the drive, please. And what is steganography? Who is going to be suspicious, unless there are where they don't belong anyway? Thanks.

man cryptsetup

EDIT:

Use the LUKS extension.

You may also look at the README_CRYPT.TXT on the boot disk. Although it's about encrypting disks during installation, I believe it gives some examples of using the cryptsetup command that you may find helpful.

And of course check at docs.slackware.com. There is probably a tutorial there.

Okay, I have had a chance to scan the man entry. One thing that is not clear is what state should the disk be in? In other words, should I do a quick format on the disk? Currently there is stuff on the dev, it was the root disk when I was trying out 14.0 so it has all the stuff for a system but I replaced it with another device for 14.1. If I install the LUKS stuff, does it overwrite the drive automatically?

This issue seems complicated. That might just be because I am ignorant but I feel the need to learn more about it before I attempt it. I am particularly concerned about how the loss of the LUKS header can render all data lost.

See:
http://www.cyberciti.biz/hardware/ho...setup-command/

Data recovery of encrypted partitions is more difficult. LUKS does have a header and thus it is even more difficult.
http://blog.miketoscano.com/?tag=luks-recovery

If you want, you don't have to use LUKS, you can use cryptsetup to make an encrypted area on the disk without a header.

`man cryptsetup`. Or at https://code.google.com/p/cryptsetup...AskedQuestions, checking around that cryptsetup site to see if there are any related docs that you like.

Steganography is hiding one message inside another message. For computers, it means doing things like having the main key write to one part of the crypt, but you have a different key to writes to a different part of the crypt. That way, parties can ask for your key, you hand over the primary, and they might not know that there is a hidden section in there. I don't think that vanilla cryptsetup deals with steganography. There are other tools to accomplish this (TrueCrypt? or its successor?). Google turns up proposals for steganography support for cryptsetup, but I haven't tried any of them.

As for the question of who is going to be suspicious, I try my best not to ask a crypto user for what purpose that the crypto is going to be used. It's bad form. If you're protecting sensitive documents, you might be better off to increase your network and physical security. When the crypt is open, it is just as available or unavailable to remote hackers as an unencrypted partition. If the data is so sensitive that you want a password to open each file one at a time, a weak-but-fast crypt combined with gpg is a nice solution. The crypt will obscure the file system layout and the data to some degree, and gpg will obscure the data really well.

But if you're asking newbie questions, you might get your newbie lessons in as well. All crypto takes extra care. At least I've lost one set of data while learning new crypto methods, whether it's zeroing out what I thought was junk partition but turned out to be the first MB of a crypt (data gone), or whether it's simply losing my only PGP key for a dataset. By the time you've learned your first bad lesson, you should have a decent feel for the cryptsetup man page. It's not the most accessible man page by any means.

As for formatting, it's up to you. I zero the partition(s) first, then make the crypt, then open the crypt, then zero the crypt. It leaves a nice trail of junk on the bare platters. You could also do the same thing but overwrite the file with /dev/urandom instead of /dev/zero. After all of this, I put a file system on the crypt and set up how I'm going to open the crypt and mount the filesystem.

Agreeing with the others here, stay away from the USB stick idea. If your LUKS header gets mangled, then your data is most likely lost. All it takes is a poor write in that header area. I've had that happen with FreeBSD geli on an old USB stick, and the conclusion was, "Oh well...good thing it was the backup of my backup and not the backup itself...because the data is gone!"

Steganography requires some imagination on the part of the user :) Don't think too many people will tell you how they do it, because that would ruin it. However, if you put your mind to it you can come up with something good.

Let's just suppose that I am interested in encryption for it's own sake, to know how to do it more than to actually do it. Besides, I can't think of any reason I should need to hide the fact that I am encrypting stuff. It is enough that I might have trade secrets or intellectual property to protect. Don't you agree?

[QUOTE=mlslk31;5261435]`man cryptsetup`. Or at https://code.google.com/p/cryptsetup...AskedQuestions, checking around that cryptsetup site to see if there are any related docs that you like.

That site appears to be uber helpful. It will take me some time to digest it but I think it answers all my questions. Thanks very much.

That is fine. There is no bad use, really, and my primary use is to transport backups offsite. I don't want to have to worry about backup media being lost or stolen. But there are some folks out there who, if you ask them to justify their use of crypto, they'll simply not respond. So I tell you my story and hope you can adapt my viewpoint to your situation.

And yes, there is a little bit of tin foil hat to my approach. I used to play with crypto to see what it was like. Then after 9/11 and before the Patriot Act, plenty of news organizations were reporting the various proposals for the government to snoop on Americans while trying to get the terrorists. At that point, my thoughts were this: I am a law-abiding citizen; if you need information from me, get a formal warrant and present it to me, I will comply; but don't go snooping on my everyday activities without permission. As it turns out, the popular ideas were brought into the Patriot Act, and the unpopular ideas were farmed out to the NSA.

FWIW, I use very little crypto online, only for sensitive information. Instead, I write about the kind of things that I'm willing to talk about in a public place. It's way easier to deliver messages in person or by phone than it is to teach a second party how to use cryptography. This was especially true before this year, when a prevailing attitude was "if you're innocent then you have nothing to hide." This year may prove that you indeed have something to hide, that sensitive information can be used to help steal your identity, that if corporations don't take care of your credit card information, you'll be watching your credit reports and credit card bills for a long time to come.

@ mlslk31
That's also the reason why steganography is invaluable today. No court can force you to decrypt something that they don't know even exists and cannot prove that it exists.

I don't use full disk encryption because it's apparently very sensitive to corruption. Then again my main concern is keeping my data safe; the secondary concern for me is to encrypt it.

So I use EncFS to create an encrypted directory. You mount it and put files in it, and those files are automatically encrypted.

But as metaschima says, it is useless if those files are ever written to the disk. You can retrieve them with PhotoRec or extundelete. As you know files are not really deleted when you "rm" them -- the memory on the disk is just flagged as writable, so it may (or may not) be overwritten at some point in the future. "shred" can be used to delete files from the disk and overwrite the memory, but ideally the files should never be anywhere except in the encrypted directory.

Some programs helpfully leak data. For example, you may expect /encrypted/whatever.txt to only exist in your encrypted directory, but a text editor may put the buffer in /tmp.

When the computer runs out of RAM, it will also write things to your swap partition, so the swap must be encrypted as well.