2

I recently went through this little noob adventure on a Linux desktop:

  1. Take a text file with sensitive info
  2. PGP-encrypt it (e.g. with Seahorse)
  3. Back it up
  4. Reinstall OS, erase hard drive, drop computer in pool, etc, etc
  5. Retrieve the encrypted file from backup, and gasp in horror to realize you can't decrypt it, even though you know the password, cause you didn't back up ~/.gnupg where your key was stored.

Why did I fall for this? Cause I used to be a Mac user, where I would create an encrypted sparse disk image, drop my file in it, and unmount. I could move this file all over the place, drop it onto any mac, mount, enter the password, and ta-da! As long as I remembered the password, all was good.

Anyone know how to do something like that with Linux?

(I hope this is related enough to programming for SOF... it's important for my programming job anyway!)

rob
  • 337
  • 1
  • 4
  • 9

7 Answers7

9

Summary: when you want to do this, use the --symmetric option when encrypting.

Let's look at the details of what's really going on here; a little understanding often helps when trying to do things right.

When you encrypt a file using GnuPG, it uses "symmetric" encryption. That is to say, it uses a single key that will both encrypt the plaintext and decrypt the cyphertext. Why does it do this? Becuase the symmetric algorithms are much faster than the public/private key algorithms (where separate keys are used to encrypt and decrypt), and for other reasons we'll see later.

Where does it get this key it uses to encrypt the file? It makes up a random one. No, I'm not kidding you here.

Now at this point you might think we have a little issue. The file's encrypted with a random key, and nobody (except that particular GnuPG process) knows what it is. So what happens next?

Here's the trick: that random key is then encrypted with other keys, and stored in the file. This is how we allow multiple users to be able to decrypt the file. For example, the backups at my company are encrypted so that both I and my business partner can decrypt them: GnuPG encrypts the file encryption key with my public key and separately with my partner's public key, and stores both of these with the encrypted data. Now I, using my private key, can decrypt the copy encrypted with my public key (or my partner can do the same with his copy), retrieve the symmetric key used to encrypt the data, and decrypt it.

So what does --symmetric do? It just encrypts that random encryption key with a symmetric algorithm itself, this time using a key based on the supplied passphrase. Now anybody who knows the passphrase can also decrypt the file.

That's nice for one file, but this soon enough becomes inconvenient when you've got many files, encrypted with different passphrases so that different groups of people can get access to them, which is one reason why we usually use the public key systems instead.

But now you've learned, the hard way unfortunately, a very valuable lesson: your private key is important! If you lose that, you lose access to anything anybody's ever encrypted using your public key. Generate it once, keep it safe, and keep it backed up in several places.

What you wanted to do was was to add the --symmetric option to allow decrypting the file with just a passphrase.

The problem was that you encrypted the file with your public key, and when you do that, you need your secret key (stored in ~/.gnupg) to decrypt it.

cjs
  • 25,752
  • 9
  • 89
  • 101
3

Curt Sampson did a great job explaining the concepts. I'm gonna give some details.

Sadly, Seahorse & friends doesn't give the option to do symmetric encryption yet, though it can handle decrypting symmetrically-encrypted files. In the meantime, as has been said, you can do your encrypting from the commandline, e.g.

gpg --symmetric --force-mdc --cipher-algo aes256 -o outfile infile

If you're happy with gpg but really want a gui, you could use my gpg-frontend Pyrite. It doesn't integrate with Nautilus like seahorse-plugins, but it's still pretty sweet, if I may say so. :)

As someone else mentioned, eCryptfs is a great option that sorta falls into this same realm, providing per-file encryption, though it does it in a much more convenient way, basically providing you a folder that transparently encrypts/decrypts all writes & reads to/from it. At first it seems like an encrypted container solution, but really it's encrypting the files individually -- once you unmount the folder, you end up with a bunch of singly-encrypted files. This article at LJ gives a good compare & contrast overview of eCryptfs vs some of the other options. Here's how simple it is to get eCryptfs going:

$ mkdir ~/vault
$ sudo mount -t ecryptfs ~/vault ~/vault
Select key type to use for newly created files: 
 1) openssl
 2) passphrase
 3) pkcs11-helper
 4) tspi
Selection: 2
....... (truncated)
$ echo hello > ~/vault/encfile
$ sudo umount ~/vault
$ ls -a ~/vault
.  ..  encfile
$ cat ~/vault/encfile
稖��)!x�"3DUfw`��ȿ_���E�����_CONSOLE�W�v0�+�'�hV���Q��VZ��eP�����l⟮j%����?O��V
....... (truncated)

If you're interested in this, also checkout the ecryptfs-setup-private command which eliminates the need for sudo and allows automating everything. Moving on.

The best other options are the ones mentioned by pts: TrueCrypt (which is cross-platform) and dm-crypt, which allows you to encrypt any block-device (e.g. partitions, logical volumes, single files) and then of course you throw a fs on top of that. Don't use Cryptoloop (predecessor to dm-crypt).

I mostly only have experience with Red Hat, Fedora, & friends, but in those you can use the lovely disk management gui palimpset to create and modify encrypted disks/partitions right out of the gate without installing anything extra. Of course there's a command-line util for this: cryptsetup ... here's a simple example to give you an idea of what's possible with dm-crypt, using cryptsetup to make an encrypted filesystem out of an extendable logical volume:

lvcreate -L 2G -n mybox volgroup
cryptsetup luksFormat /dev/volgroup/mybox
cryptsetup luksOpen /dev/volgroup/mybox mybox
mkfs.ext4 /dev/mapper/mybox
cryptsetup luksClose mybox

Once you've done that, Nautilus should have no trouble auto-detecting it and then you can unlock it and do a secure user-mount from there.

EDIT: I feel silly. I was browsing through gpg tags when I came across this question. I didn't notice how old this was until I finished typing everything and was about submit it. Oh well. Perhaps it will come in handy for posterity.

rsaw
  • 3,315
  • 2
  • 28
  • 30
  • **Addendum:** I think the LJ article I linked talks about how important it is to have encrypted swap when using any of these encryption schemes. In any case, check out the man page for the **`ecryptfs-setup-swap`** helper tool if you're not setting a system up from scratch. (Easy as pie.) – rsaw Mar 05 '12 at 09:02
2

TrueCrypt is a user-friendly disk encryption solution which works on Linux (and other systems too).

Linux-only lower level solutions are dm-crypt and crpytoloop.

pts
  • 80,836
  • 20
  • 110
  • 183
2

I use ccrypt, which is available in Cygwin as well.

   ccrypt is a utility for encrypting and decrypting files and streams. It
   was designed to replace the standard unix crypt utility, which is noto‐
   rious  for  using a very weak encryption algorithm.  ccrypt is based on
   the Rijndael block cipher, which was also chosen by the U.S. government
   as      the      Advanced     Encryption     Standard     (AES,     see
   http://www.nist.gov/aes/). This cipher  is  believed  to  provide  very
   strong cryptographic security.
kdgregory
  • 38,754
  • 10
  • 77
  • 102
1

I used mcrypt. It supports several modern encryption algorithms and it's pretty comon on linux machines (Or at least it's easy to obtain precompiled package on most distors).

Barnaba
  • 657
  • 5
  • 19
1

ecryptfs is easy to set up and use.

  • Upside: you don't reserve space in advance; it works as a layer on top of the filesystem

  • Downside: filenames aren't encrypted. Obviously you can work this by zipping or tarring your entire tree and letting ecryptfs encrypt the zip or tar file, but it's a nuisance.

    UPDATE As of March 2012 this problem is solved (and has been solved for some time): ecryptfs encrypts filenames. I couldn't easily find the version number or date at which this feature was introduced.

Norman Ramsey
  • 198,648
  • 61
  • 360
  • 533
0

You can also use openssl to encrypt files.

johndodo
  • 17,247
  • 15
  • 96
  • 113