Off The Grid
   Simple listserv
   xml tools
Karel as an adult

What's fe?

Warning: Consider this alpha software.
Latest changes: fe also protects swapfiles of emacs and vi.
Plus: Usability updates.
Download: fe.tar.gz
Installation: Unpack and read INSTALL.txt
How it works: Read TECHINFO.txt, it's in the distro
Weakness:Yes, read about it below
Builds on: MacOSX and Linux. Other Unices should be doable.
Disclaimer: Use at your own risk. Works for me, but who knows?
How's the crypto: I think it's good. So don't trust it ;-)
Copyright: © Karel Kubat 2015ff. Distributed under GPLV3.
Contact: Questions, remarks? Mail me!
Fe is an encryption utility aimed at separate files. Below is an introductory screen capture, have a look if you want (it shows version 1.01, but the concepts are still the same). Or just read on below!

Just encryption?

Encryption of files is part of fe.

But wait, there's more. Fe is a "somewhat smart" utility. It can prepare an encryption layer that other processes use. For those processes, accessed files are perceived as plaintext, while in fact they are guarded by fe and reside on disk only in an encrypted form.

Let me repeat that. The files reside on disk only in an encrypted form. They are never in an unencrypted state, unless you decrypt them yourself and put the plaintext version on your disk.

What good is that? There is a number of use cases:

Why use fe and not a different utility?

There are many encryption utilities around. I think that fe has its particular strengths:

Encryption and decryption keys

Fe uses symmetric encryption; which means that the same key is used for both encryption and decryption. Actually, fe doesn't even know if it's encrypting or decrypting, it's just "transcrypting" bytes.

When fe needs to transcrypt data, then it needs a key. A key can be given to fe in any of three ways:

Don't loose your key!

Fe doesn't store key information anywhere. And it can't detect whether the right key is used when decrypting (it just transcrypts bytes, remember). Therefore, don't loose your key. There is no way to get back plaintext information once it's been encrypted and the key is lost.

While that looks like a flaw, consider this. Given the fact that there is no information whether a transcryption is using the right key or not, there must be countless keys that produce some meaningful output. For example, if a brute-forced key decrypts a file to say "hello", is that the right key? No-one knows; there's also a key to decrypt the same bytes into "world". Brute-forcing has just become a bit harder. (Nevertheless, make sure that you use "good" keys when using fe.)

What if you transcrypt using the wrong key?

Imagine that you have started your top secret password file ~/etc/mysecretfile.txt using key aaa. Next time that you're editing it using
  fe emacs ~/etc/mysecretfile.txt
you enter by mistake the key aab. Of course you meant to enter the right key aaa but you mistyped.

Consider the states of the file, depicted in the following ASCII art figure:

              key: aaa                   key: aab
                          aaa-encrypted               aab-encrypted
  plain text ------------> version of    ----------->  version of 
			   plain text               aaa-encrypted fie
Now what? If you remember all the keys in the chain of events, then you can re-create the aaa-encrypted version:
    # Covert aab-encrypted back to aaa-encrypted
    fe -t ~/etc/mysecretfile.txt -k aab
    # Retry editing, and now try to enter 'aaa' instead of 'aab'
    fe emacs ~/etc/myscretfile.txt 

How to encrypt existing files?

If you have plaintext files and want to encrypt them for usage with fe, then there are basically two options: Please note that since there was a plaintext version on disk, you can't be totally sure that the file contents can't ever be reconstructed. If you want to use fe, you might just as well not use a plaintext version of your secret files.

Fun fact: What if you would use the command

    fe   cp plaintext.txt encrypted.txt
Here's what.

Fe's weakness

Fe has a weakness that you must be aware of.

The fe process that prompts for a key, also publishes an environment variable called FE_CTX, which holds a numeric ID. This ID is the "shared memory id" where fe's context is stored: the transcryption target files, a couple of internal settings, and the secret key, although in encrypted format.

The reason for this is that fe must provide a way by which next transcryption layers (under a bash, under a vi, whatever) what they must do.

The weakness is, that if any program that's started by fe captures the value of this variable, then they can examine the shared memory block and get at the data. Potentially then can then transcrypt the target files. So make sure that when using fe, you only start 'trusted' programs - meaning, ones that behave and where you can safely assume that they don't examine the value of $FE_CTX, rip your shared memory, and use that information to get at your secret files.

All this means that when you type

    fe vi ~/etc/mysecretfile.txt
then for the running time of vi, that environment exists. After that it's gone. You can very probably trust vi, so that's ok. But hey, be aware. Incidentally, if you can't trust vi with your data, then you have a whole other problem on your hands. For example, if your vi just sends whatever it reads off to a remote server, then no encryption at all will help you. So the fact that you should only run programs that you trust, is hopefully no real news.