Not to rip into to John's code but there are some common security and cryptographic mistakes. Security and cryptography are hard problems. Cryptographic algorithms are easy. Integrating cryptography into a system properly is much harder. On Sun, Apr 19, 2009 at 06:09:48PM -0400, John C Nash wrote: > > tpw=`date` # Use backquote to execute date > echo "$tpw\n" > tpass > echo "$tpw\n" >> tpass > cat tpass | encfs -S ~/tspace/ ~/etspace/ The above is pointless as the key is easy to guess. Over the course of a month there are only 2.6 million keys (31*24*60*60). If the attacker can guess the day the key was generated there are only 86k keys. Use /dev/random instead[1]. The following will generate a 256bit key. $ dd if=/dev/random bs=1 count=32 > echo "Destroy this?\n" > cat tpass > rm tpass # for security The rm command only removes the directory entry of a file. The file can still be recovered. Use scrub or shred instead. Better still don't store the keyfile at all: $ dd if=/dev/random bs=1 count=32 | encfs ..... > cp $1.cpt ~/etspace/$1.cpt > ccrypt -d ~/etspace/$1.cpt > less ~/etspace/$1 > echo "Now scrub it\n" > scrub ~etspace/$1 As mentioned the command ccat will decrypt the file and send it to stdout instead of the filesystem. From the manpage ccat is equivalent to 'ccrypt -d -c'. A common security problem is security overkill. Too much security results in a complicated process. A complicated process is harder to audit and more likely to have problems. A complicated proces can also introduce new vulnerabilities. I would consider the original bash script to be overkill. The script does a lot, but the additional protection seems minimal at best. Two minor technical issues: > sudo mount -t tmpfs -o size=500k,nr_inodes=200 tmpfs /home/john/tspace >From a quick scan of the encfs website I don't think you need the tmpfs. The example given on the website is: $ mkdir /tmp/crypt-raw $ mkdir /tmp/crypt $ encfs /tmp/crypt-raw /tmp/crypt If encfs is any good using tmpfs should provide no avantage. If there is an advantage then encfs should not be used. > sudo umount ~/etspace Encfs uses FUSE (filesystem in User SpacE) so you can un-mount as a regular user: $ fusermount -u ~/etspace John also wrote: > > Some of you may remember my OCLUG talk on tools for carrying encrypted > files on USB. Still on this topic, I'm wondering the best way (for the > moment just in Linux) to simply view the contents of an encrypted plain > text file (my password list!) in a way that doesn't leave a backup file > around, and clears memory etc. For cross platform use you should look at other tools. GnuPG is crossplatform and could easily replace ccrypt above. Use the gpg --symmetric option with --encrypt and --decrypt. I would use GnuPG over ccrypt regardless: many smart people have looked at the GnuPG code. There is also PasswordSafe which is designed to securely store passwords. There is a windows gui and command line tools for Linux and Mac. None of the above clears memory. That is a hard problem. There is nothing to prevent the decrypted file from being swapped out to disk or sitting in memory long enough to be recovered. The swap problem can be handled with an encrypted swap. The only way to deal with the residual memory problem is to use a completely trusted system. Of course if you are using an untrusted system there are many other attacks that are easier to pull off then reading the ram. When devising any security system it is generally best to protect against the easy attacks. Protecting against the harder attacks generally creates complexity (with a greater chance of error) for minimal additional security. [1] /dev/random is actually not a great source of entropy for encryption keys. Openssl and GnuPG both implement their own algorithms for this reason. -- sg