Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

Easy encryption and decryption of directories with GPG UNIX
I was looking for a way of encrypting a directory using GPG. I tried writing an AppleScript, but found it impossible to get a password into the script (anybody know how to do this?). So I ended up writing a shell script.

These scripts encrypt and decrypt a "crypt" directory in the user's home directory. At the same time, each script copies an alias onto the desktop to perform the reverse operation. So encrypt.sh encrypts the crypt directory and copies an alias to decrypt.sh to the desktop.

A pre-requisite for these scripts to work is an installation of gpg, the Gnu Privacy Guard.

I have set the icons on these aliases to be some sort of warning colour. If the alias is a green parrot (I used these icons from Adam Betts at Xicons.com) and says decrypt, it means that the crypt directory is currently encrypted. 

[robg adds: I have not tested these scripts, and the author admits they aren't really fully documented. If someone wants to try them, please post your results. Read the rest of the hint for the scripts.]

In the scripts, I move the aliases rather than copying them because copying then (with cp) seems to loose the icons (again anybody know how keep the icons using a shell copy command?). I used the gpg -c symmetric encryption which doesn't use keys to encrypt the file, rather it uses a pass phrase.

encrypt.sh
#!/bin/sh
#
# Encrypt the crypt directory
#

cd ~
NAME=crypt.tar.gpg.`date+%y%m%d%s`.bak

if test -f ./crypt.tar.gpg
then 
  cp ./crypt.tar.gpg ./LocalBackup/$NAME
  rm ./crypt.tar.gpg
fi

test -d ./crypt

if [ "$?" -ne "0" ];
then
  echo "No crypt directory to Encrypt... quitting"
  exit 1
fi

gnutar -c -f ./crypt.tar ./crypt/
gpg  -c ./crypt.tar

if [ "$?" -ne "0" ];
then
  rm ./crypt.tar
  echo "Error encrypting Archieve... quitting"
  exit 1
fi

rm ./crypt.tar
rm -r ./crypt

if test -f ~/Desktop/encrypt
then
  mv ~/Desktop/encrypt /Applications/AdminTools/EncryptionScripts/encrypt  
fi

mv /Applications/AdminTools/EncryptionScripts/decrypt ~/Desktop/decrypt
decrypt.sh
#!/bin/sh
#
# Decrypt the crypt directory
#

cd  ~ 
gpg --decrypt ./crypt.tar.gpg > ./crypt.tar 

if [ "$?" -ne "0" ]; then
  echo "Unable to decrypt Archieve... quitting"
  exit 1
fi

if test -d ./crypt
then
  mv crypt DELETE_ME_cryptBak
fi

gnutar xf crypt.tar

if [ "$?" -ne "0" ]; then
  echo "Unable to un tar Archieve... quitting"
  exit 1
fi

NAME=crypt.tar.gpg.`date+%y%m%d%s`.bak
if test -f ./crypt.tar.gpg
then
  cp ./crypt.tar.gpg ./LocalBackup/$NAME
  if [ "$?" -ne "0" ]; then
    echo "Unable to un tar Archieve... quitting"
    exit 1
  fi 
  rm ./crypt.tar.gpg
fi

rm ./crypt.tar

if test -f ~/Desktop/decrypt 
then
  mv ~/Desktop/decrypt  /Applications/AdminTools/EncryptionScripts/decrypt     
fi

mv /Applications/AdminTools/EncryptionScripts/encrypt ~/Desktop/encrypt

exit
To use the scripts, you will obviously have to set up the directory structure that they require. This is basically: A backup directory, the scripts directory and aliases for the scripts. This may be a poorly documented hint, but I find this automation really useful and thought I would share it.
    •    
  • Currently 1.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (1 vote cast)
 
[6,962 views]  

Easy encryption and decryption of directories with GPG | 15 comments | Create New Account
Click here to return to the 'Easy encryption and decryption of directories with GPG' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Easy encryption and decryption of directories with GPG
Authored by: stukoch on May 21, '03 10:24:57AM

I have a very simple method I use to password protect files. It does not encrypt them, but it does make them difficult to open without the proper password. The problem is that this method can be easily defeated by booting into OS9.

1. Select the file
2. Open Get Info in the File Menu
3. Click the Ownerships & Permissions drop-down menu
4. If the padlock is closed, click it to open it
5. Click the Owner list and select Nobody
6. Click the padlock to close it
7. Make sure that the other access groups are set Access: No Access

That should do it. When you want to open the file you must do this process again, but select yourself in the Owner list.

-Stuart



[ Reply to This | # ]
Easy encryption and decryption of directories with GPG
Authored by: SOX on May 21, '03 11:18:20AM

You might want to use
mpmac, ditto, rsyncX or psync
instead of cp and mv



[ Reply to This | # ]
Easy encryption and decryption of directories with GPG
Authored by: bitwiseshiftleft on May 22, '03 04:15:29AM

Why? He tars them anyway.



[ Reply to This | # ]
Easy encryption and decryption of directories with GPG
Authored by: foobar104 on May 21, '03 12:46:09PM

I'm a little confused. Why would one concoct a less-than-fully documented workaround to use GPG for this when one could just as easily use user-friendly, fully documented PGP 8? The freeware version works very well, and if you want to use it commercially the commercial version is reasonably priced.



[ Reply to This | # ]
Easy encryption and decryption of directories with GPG
Authored by: bluehz on May 21, '03 01:37:07PM

One good argument for using GPG at least in my case arises from a paranoia, but I feel in the case of security a paranoia is justified. Stems from this... years ago when Zimmerman (the originator of PGP) and the Federal Govt were were locked in heated battle over PGP, there was a lot of talk at the time of putting back doors into PGP. No one really knows if this ever happened, and I suspect not... BUT... I prefer to take the high road and use the open source, fully code inspectable, version GPG. Another reason - is personal... Network Associates IMHO are d*@%ks! They possesed PGP code and refused to update it for Mac OS X, yet they continued development of Win versions. They bookshelved the code for over a year trying to find a buyer for the code who would hopefully continue development and create OS X version of PGP. They refused to release BACK into the public domain what was oiginally free software. Instead they preferred to horde the code and prevent OS X developers from developing an OS X version unless they purchased the code.

... those are of course my own personal opionions.



[ Reply to This | # ]
Easy encryption and decryption of directories with GPG
Authored by: calroth on May 22, '03 04:57:46AM

Network Associates doesn't own PGP any longer. It's not worth carrying that particular grudge over to the new company.

The source code to PGP is available, but you have to jump through hoops to get it, and you're not allowed to use it for anything but verifying that, when built, it's exactly the same as the standard PGP binary.



[ Reply to This | # ]
Easy encryption and decryption of directories with GPG
Authored by: bitwiseshiftleft on May 22, '03 04:22:42AM

PGP doesn't encrypt folders. If you try it, you get another folder with a bunch of pgp files in it. That's a PITA to work with, especially for a backup. Furthermore, you might not want the files' names to be known. So basically you'd want to stuff it, then PGP it. This is much more of a pain than my .bashrc addition (see below), although as I mentioned, you'd have to make some small modifications to preserve metadata (easy with hfspax, although hfspax itself is a poorly-documented kludge).



[ Reply to This | # ]
Easier encryption and decryption of files and folders
Authored by: bitwiseshiftleft on May 22, '03 03:52:35AM

The article is bloated. Use pipelines, it's trivial.

in .bashrc:
function encfold() {
tar -czf - $* | gpg --encrypt
}

function decfold() {
gpg --decrypt $1 | tar -xzf -
}

then you just have to
$ encfold foo bar baz > encrypted.tgg
(tgg = ad-hoc contraction for .tar.gz.gpg; tgz.gpg or just .gpg might be better)

and to decrypt,
$ decfold encrypted.tgg

No temp files, no errors except those provided by the utils, no nothing.



[ Reply to This | # ]
Easier encryption and decryption of files and folders
Authored by: bitwiseshiftleft on May 22, '03 04:03:54AM

oh, hmmm. it seems he deletes the folder too... but I would argue that this is not optimal (although one could add a simple && rm -r $* to my script). What one should do rather, if one wants to delete them at all, is overwrite them (n times with specific data if you're really paranoid) and then rm them. The wipe command in PGP does this, or you can write a simple shell/perl script or c program to do it. Heck, you can do it with find, a for loop, and dd.

I actually have a tar+gpg option in my standard backup script for stuff like email and chat logs, although it works rather differently due to modularity and slightly different goals. I'm not worried about my hard disk being compromised, but rather about the rather personal info which would be on the backup cd.



[ Reply to This | # ]
Easier encryption and decryption of files and folders
Authored by: amacaulay on Jul 17, '03 02:29:03AM

or use rm -P

"-P Overwrite regular files before deleting them. Files are
overwritten three times, first with the byte pattern 0xff,
then 0x00, and then 0xff again, before they are deleted."



[ Reply to This | # ]
One more caveat...
Authored by: bitwiseshiftleft on May 22, '03 04:13:15AM

Neither the script given nor mine preserve metadata. If you want to preserve ownership and stuff (doesn't matter for me because it's UNIX text files I own, but it could for you), add a p to the tar options (of course, you have to decrypt as root for this to make a difference anyway...). If you want to preserve resource forks and HFS+ metadata, you'll have to use hfspax or the like.

Also note that you can't "just use PGP's encryption" as another poster suggested, because PGP encrypts files in place. IE, if you run PGP on a folder with 50 text files in it, you'll get a folder with 50 text files and 50 pgp files. So you'd have to stuff it or something first.



[ Reply to This | # ]
One more caveat...
Authored by: foobar104 on May 22, '03 04:34:09AM

I'd hardly go so far as to suggest that the necessity to turn many files into a single file (with Stuffit or what have you) means one cannot use PGP. In point of fact, stuffing or zipping a collection of files and then encrypting the resulting archive is quite easy to do, and very effective. Far more so, I dare say, than twiddling with dodgy UNIX shell scripts. After all, with the free Stuffit product and the free PGP product, the process is a simple matter of two drag-and-drop operations. A breeze, and absolutely foolproof.



[ Reply to This | # ]
I disagree...
Authored by: bitwiseshiftleft on May 22, '03 02:35:30PM

Um. DropStuff isn't free (well, it effectively is, but you ARE supposed to pay for it).

And for what I'm doing, that shell function (mine is not a script) is pretty much fool-proof. It's also faster because (1) tgz is faster than DropStuff, (2) CLI apps generally load faster than GUI apps, (3) no DropStuff registration to click through, (4) as coded there, it assumes encryption to the default key, which is what I want to do, and (5) DropStuff and PGP are not in my dock.

I like UNIX, I'm comfortable with the shell. And furthermore, I work with UNIX and Linux boxes a lot, and it's nice to have my files in a format they can understand.

The only files it would fail on for me are finder icons and aliases, and I don't care so much about those anyway (I use symlinks more). They're certainly unimportant on a backup disc.



[ Reply to This | # ]
I disagree...
Authored by: foobar104 on May 22, '03 03:09:44PM
And for what I'm doing, that shell function (mine is not a script) is pretty much fool-proof.

I mean no offense, but "pretty much fool-proof" is just like "a little bit pregnant."

It's also faster

That's hardly significant, even if true. We're talking about taking a two-second operation and turning it into a 1.75-second operation.

I like UNIX, I'm comfortable with the shell. And furthermore, I work with UNIX and Linux boxes a lot, and it's nice to have my files in a format they can understand.

That's fine, but that pretty much moves this particular item out of the realm of a Mac OS X hint and makes it a UNIX hint. Most of the people who use Mac OS X are Mac users, not UNIX users, and your suggestion would not be appropriate for them.

[ Reply to This | # ]

I disagree...
Authored by: amacaulay on Jul 17, '03 02:36:51AM

Not wanting to perpetuate an argument, but the hint is in the Unix section of the site.

As a Mac user of many years and occasional Unix user, the foundation of MacOS X on BSD gave me the best of both worlds at a point where I didn't have the time to learn to install and maintain Linux but did need regular access to a Unix command line.

Sorry to go off topic, but I would hate Hinters to be put off submitting hints that I find both useful and interesting.



[ Reply to This | # ]