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
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:
You store your passwords, credit card data etc. in a file on disk.
You want the file to be encrypted, so that no one (not even "root")
can see. So every time you want to update that file, you type:
fe emacs mysecretfile.txt
(Don't worry. You can also use vi. The "emacs mysecretfile.txt" part
above is just a command that fe runs for you.)
You could also use flag -t (for "target"), as follows:
fe -t mysecretfile.txt emacs mysecretfile.txt
but fe is smart enough to guess that the commandline argument should
be a target for encryption and decryption.
If you want to look up your password for say amazon.com, you type:
fe grep amazon.com mysecretfile.txt
Here, fe will assume that "amazon.com" and "mysecretfile.txt" are
encryption targets, but since "amazon.com" probably isn't a file, that's
fine. If you need to be sure to restrict the target to only
"mysecretfile.txt", then you can always use flag -t:
fe -t mysecretfile grep amazon.com mysecretfile.txt
You want to start an entire new shell on top of fe's encryption
layer, so that the encrypted file $HOME/etc/mysecretfile.txt appears
unencrypted to all stacked processes, while in fact it's in
encrypted form on disk. You type:
fe -t ~/etc/mysecretfile.txt bash
Next, inside that bash, the file appears plain-text. E.g.,
will show the plaintext content. When you run
then emacs will just see a plaintext file.
Why use fe and not a different utility?
There are many encryption utilities around. I think that fe has its
Full disk encryption utilities such as truecrypt "unlock" the disk
once the system boots. If an attacker gains entry into a running
system, they can access plaintext files. Also, user "root" can see
File-based utilities such as pgp work with two files: one encrypted,
one plaintext. If you store sensitive information in a pgp-encrypted
file, then your workflow is probably: decrypt/edit/encrypt; and
therefore, the plaintext version appears on disk once the utility is
asked to decrypt it. The same also goes for e.g. encrypted zip
files. Again, others can see it if they time it right.
The case is even stronger when you consider the underlying disk.
Once a plaintext file has been on the disk (even though it's removed
now), it can possibly be reconstructed. This is even more true for
SSD's; the internal processor of an SSD will try to postpone writing
over previously used sectors so that there's an even usage spread.
So, on an SSD, the contents of a deleted plaintext file might be in
more than one location.
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:
Using the command line switch -k, as in:
fe -k mysecret ....
This option is unsafe and should be used sparingly, because a
simple process listing using "ps" will reveal the commandline and
hence the secret key.
Using the environment variable FE_KEY, as in:
This option is unsafe and should be used sparingly, because the
secret remains in the environment and can be seen. For example, if fe
spawns a shell, then a simple "printenv" will reveal the key.
Furthermore, on Linux, user "root" can access the environments of
running programs via /proc.
Using none of the above. In that case fe will either:
If you're on a terminal, fe will prompt twice for the key (and
stop if the two entered values don't match)
If fe's stdin is a pipe, as in someprog | fe ...,
then fe will read the key, just once, from the pipe.
This option is the safest.
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
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
key: aaa key: aab
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:
Use fe's flag -f, as in:
fe -t plaintext.txt
mv plaintext.txt encrypted.txt
Have a standard utility like "cp" do it for you, whilst instructing
fe that the output file is a transcryption target:
fe -t encrypted.txt cp plaintext.txt encrypted.txt
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
In absence of specified transcryption targets, fe will assume that
both plaintext.txt and encrypted.txt should be 'protected'.
Hence, when cp reads a buffer from plaintext.txt, it won't
receive the true file contents, but a transcrypted buffer.
The program cp won't know that this buffer is transcrypted (file
contents are transparent to invoked programs right?), so it will
want to write that information to encrypted.txt.
And hence, when cp tries to write encrypted.txt, fe will
make sure that the buffer is transcrypted again, into - well,
So in this case, you've just copied one plaintext file onto
another, but with lots of overhead.
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
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.
From the Real Life Medical Charts file:
On the second day the knee was better and on the third day it had