home | list info | list archive | date index | thread index

Re: [OCLUG-Tech] safe viewing of encrypted file

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

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.