Tags

, , , , , , , ,

Firstly I should point out that EncFS uses the local system’s OpenSSL library, which has recently been patched (yes, again) for the Ubuntu and Linux Mint repos. Neither of the recently-discovered vulnerabilities are a problem here anyway, as far as I can tell.
But this is a follow-up to my other post on setting up EncFS, and will deal with the command line method. It’s remarkably easier than it looks. In fact, it probably takes longer to read this post than set up an encrypted filesystem in practice.
As previously explained, EncFS works at the high level using a source and a target directory: A file is dropped into the source directory, and it appears in encrypted form in the target directory. The target directory, containing the encrypted files, can be later mounted as a virtual filesystem and the contents decrypted.

Anyone who’s tried following the other quick guides for setting this up in the command line has probably run into error messages stating the new directories cannot be created by encfsctl. The other guides typically suggest a workaround that involves messing with fstabs and group accounts. Well, a less cumbersome workaround is simply to create the source and target directories before running the $encfs command.

With the source and target directories created, they just need to be defined as EncFS, using the following syntax:
$encfs /target /source

For this demonstration, the target directory is /Ciphertext (on a USB drive) and the source is /Plaintext.

encfs-create-volumes

The ‘expert mode‘ option is chosen instead of ‘paranoia mode‘ here because it’s important to know precisely how the system’s being configured, and that a small write error isn’t going to render an entire volume unrecoverable.

encfs-supported-ciphers

The main choice is between AES and Blowfish. Tricky one, as they’re both symmetric ciphers that work in roughly the same way, but it’s comparing apples to oranges, in that AES was designed as a replacement to DES, and Blowfish is an older cipher intended to replace IDEA and has been superceded by Twofish. UWN Thesis has done a huge amount of research into this, which might be worth looking at first.
I doubt that actually matters in the real world. If the Powers That Be really wanted your data, they’d instead attack the implementation, or some key management flaw, and the chances are you’d give the password if the alternative is jail time.

Key Size
This brings us to the key size. Don’t fall into the trap of thinking bigger is always better. You see, the cryptographic key itself is typically the hash digest of the password, so a 256-bit key is not going to provide 256-bit security if the password only has around 64 bits of entropy. Fortunately EncFS solves this little problem by salting the hash. To actually get the full security of a 256-bit key, if straightforward password hashing was used, a password of 32 completely random characters would be required.

The decision about block size also becomes important in relation to key size and cipher modes, and potentially similar key/block sizes could mean less security. If Electronic Code Book (ECB) mode was being used, each block is encrypted with the same key, which means two identical plaintext blocks would theoretically result in identical ciphertext blocks. It’s not an issue with EncFS, but it’s something to think about when configuring stuff like this.

File Name Encoding
Another important one, unless you want the filenames to be completely viewable to anyone with physical access to the storage medium.

encfs-filename-encoding

Once everything’s set up, the two directories should give a working EncFS volume and a mount point.

source-target-directories

Dropping a file into the /Plaintext directory results in the file appearing in its encrypted form in /Ciphertext. So far, so good.

What happens after the machine is rebooted and the USB drive removed? This is where things get slightly tricky. The same command is used for mounting an existing EncFS volume, but this time with the ‘nonempty‘ option:
$encfs /[encrypted] /[unencrypted] -o nonempty

remounting

And the encrypted volume should allow for on-the-fly encryption as before. Once this has been done several times, it should become second nature.

Note the volume is also listed to the left of the file manager. I expected this mounting procedure to also work on another machine, and it did:

encfs-other-mounted

Advertisements