From the Unix and Linux StackExchange website, I found this question.
“I use a Mac with an
encrypted hard drive. I've a lot of
videos in a directory "videos", which I backed up using encfs to
Google Drive. Since I don't want to
encrypt the "videos" directory on my hard drive itself again, I
decided to use reverse encryption. This uploaded the encrypted files to
Google
Drive:
encfs --reverse videos/
~/Google\ Drive/drive/
If I'd sync the contents
from Google Drive now to the hard
drive of a second computer, would I be able to decrypt it, since the
.encfs6.xml file was created in the "videos" directory and this file
doesn't get synced to Google Drive.
Contrary to
what I’ve found on the web, my experience is you can do this with encfs
either
in the forward or reverse mode of encfs, although a number of caveats
come into play for reverse mode. You can use more than 2
computes
as synchronized peers. You
can do it with commercial cloud services such as Google's Drive, or
Microsoft OneDrive, or Dropbox, or you can use it with a peer-2-peer
established architecture such as BTSync and Syncthing. This web
page documents my efforts with Syncthing
First, two pushbacks on the original question:
The trite answer to your question is, “You’re right about the xml file. Just manually copy it over to the second computer and you’re good to go.” There is really much more to understand, though…
I will assume you first get your peer-2-peer cloud service or commercial cloud service running. In other words, all the ~/cloudsync directories in the diagram below are correctly synchronizing among your peers. Although the diagram shows a generic "~/cloudsync" directory, the actual directory name could be the "Sync" directory with Syncthing, or the "Google Drive" directory with Google Drive, etc. In the examples below, the encrypted directory is a sub-directory because in the root sync directory, I keep an un-encrypted assortment of utilities and tools such as BTSync, Syncthing, TrueCrypt, 7zip, TrueCrypt volumes, etc.
Encfs in the normal (forward) mode synchronizes stored encrypted data with a virtual plaintext view of the files. In the reverse mode, it makes stored plaintext data visible as an encrypted virtual view of the files. It’s just an issue of which side is the real data and which is a virtual view of the data. The clear text xml file is always stored with the real data.
The diagram shows the variety of nodes that might be connected to your cloud. I diagrammed both Windows and Linux / Mac based nodes. Under the Linux node type, I showed both an encfs forward (normal) and encfs reverse structure. It might be confusing that the Linux examples using the encfs reverse mode show both real data and virtual data in the synchronized directory. I meant to diagram that when encfs is running the directory is a virtual mount. However, when encfs is not running, the underlying directory would receive a real copy of the data from the cloud.
Under Windows, a drive letter is shown. Using EncFSMB, this will be a forward mode virtual mount, and the OS does not let you merge it to place it over a mount directory - it will be a drive letter obtained by encfs.
The
rest of this web page will discuss how to set up the encryption layer
that implements the outer layer of arrows to the clear text data - with
some cautions and caveats.
For each node, you
will need to decide if you want to store the actual data as clear
text (encfs
reverse mode), or store the actual data encrypted
(encfs
normal or forward mode). The cloud sharing you set
up can use a mixture of
the two methods. For
Windows computers, I use EncfsMP, which does not allow a reverse
mode, so I didnt show that in the diagram.
This option uses the encfs
normal
(forward) mode. This
is the only option
available under the Windows EncfsMB program. When encfs is not
running, you will not have clear text files available to you.
Synchronization puts enrypted data in the cloud.
Although all the sync directories are assumed to be working, there is no data yet in the encrypted subdirectory, so it needs to be populated by running encfs on the first node. If you're on Linux or a Mac, create the clear text directory ~/cleartextfiles on the local node. With Windows, it will be a drive letter, so you don’t need to prepare a specific mount point.
Under Windows, use EncfsMP to "Create New EncFS". I specified a virtual mount name of "cleartextfiles", browsed to the ~/cloudsync/encrypted directory, entered a password, and accepted the rest as default.
Use the EncFSMP Mount button to mount the encfs you created. The next screen shot shows after mounting with the password.
If
you are using Linux, create the ~/cleartextfiles
mount point and then running encfs will create the file system and
mount it in a single step.
On the second node, the sync program will have already populated the ~/cloudsync/encrypteddirectory. This must include the unencrypted xml file. If the xml file comes from a reverse encfs node, you'll have to manually put a NOT encrypted copy into the encrypted data directory so other forward encfs nodes can find it there.
On Windows, run EncFSMB using the "Open existing encFS" button.
With Linux, run encfs to make the virtual real data available. Use the same command line, which will run without all the setup options (because it sees the xml file is already present.
Notice that if the encfs mount accidentally quits (or encfs starts after sync on bootup), there is no impact across the peers' sync operations. Just bring up encfs when you can and clear text files will become available.
With
the encfs reverse mode, clear text data is stored on your local hard
drive and a
virtual encoded translation of your data is made available at a mount
you choose. Unless you’re totally disciplined about running
the cloud sync program if an
only if encfs
is running, there is a data instability you need to be aware of.
When
you have encfs running, the ~cloudsync/encrypted directory will
have certain virtual files visible to the sync program. When
encfs is not
running, a
different set of files (or maybe no files) will be visible to the sync
program.
The
overlaid mounts can cause problems. This
is because the encrypted directory in the reverse mode is an
overlaid mount. Everything is great as encfs populates it with an
encrypted view of whatever you put into the ~/cleartextfiles directory,
but as soon as you dismount the encypted directory, the underlying
actual file storage at ~/cloudsync/encrypted
(which probably has
nothing), is exposed to the sync program, which will propagate the
apparently deleted files through the cloud. This is probably
NOT what you want. The best that could happen is that the instead
of propagating absence of files into the cloud, the sync program
propagates the now-missing files back into the underlying mount point
directory. To prevent these awkward situations, the sync program
needs to be able to designate
a dismountable directory for special treatment (no sync if nothing is
mounted). Unison allows
this. BTSync (Resilio) and Syncthing do not as of early
2017.
You can work around the overlaid mount issue by mounting encfs first and then bringing up your sync program - and ensuring this is always true: encfs must be running and generating the encrypted view at all times sync is running.
Another work around with Syncthing is to not use a subdirectory - store all your encryption in the root directory. In this case, Syncthing will at least recognize if the mount is not overlaid and will prevent propagating file deletes. Sync won't occur but at least your data already up on the cloud will be intact. In my use case, I want my encrypted directory below the syncroot folder, so I can't do this. Testing with BTSync and Google Drive continues.
The
second data issue is that the xml file will not automaticallly
propagate from the first to other nodes. It is always kept with
the real data not the virtual view (the clear text directory in the
case of encfs reverse mode). You have to manually assist getting
the xml file throughout the network. You can put a clear text
copy in the encrypted sync directory and it will show up on the other
nodes. If other nodes will run in reverse encfs mode, you need to
subsequently put a copy in the clear text directory on that node.
The assumption is that
your clear text data is already available in the ~/cleartextfiles directory.
I
don't know of a Windows program that does reverse mode, so I'm showing
only the Linux commands. Here's how
to add the encryption.
Encfs reverse mode will create the xml file in the clear text directory. Like everything else in that directory, encfs will encrypt it and make it visible in the encrypted directory. This is a superfluous happening. Just leave it there and you’ll never use it. Also encfs will populate the ~/cloudsync/encrypted mount point with a view of your data.
The
screen clip below uses Midnight Commander on the Windows Subystem for
Linux to confirm over ssh that both syncrhonized encrypted directories
are the same. The only file initially present is the xml file
itself, which is created in the clear text directory (and subsequently
visible in the matched encrypted mount as an encrypted file when encfs
is running). Notice the file length
of 1077
bytes, which is the same as the clear text file. This is one
of the reported weaknesses of encfs because although someone can't read
the file, it's very reasonable for someone to determine that it is an
encfs configuration file, making it easier to break your security keys
and passwords.
It's worthy of note what happens if you dismount the encfs encrypted view while the sync program is running (in the text clip below, I had created another file in the cleartext directory, so that's why a second encrypted file is in the encrypted mount below).
pi@raspberrypi:~
$ mount
...
encfs on
/home/pi/cloudsync/encrypted type fuse.encfs
(rw,nosuid,nodev,relatime,user_id=1000,group_id=1000,default_permissions)
pi@raspberrypi:~ $ ls
cloudsync/encrypted/
EbQB7a3EgU-3K,wPA7NBsvsw
G9b3Tn-vycyzDN,28TsAgPcZ
pi@raspberrypi:~ $ sudo umount
cloudsync/encrypted
pi@raspberrypi:~ $ ls
cloudsync/encrypted/
pi@raspberrypi:~ $
The important point to note is that if you stop encfs by dismounting the encrypted mount point, the files are gone! This is the data instabilitiy I explained above - the sync program is going to propagate the file "deletions" throughout the cloud. The files will only be left on the clear text directory of the computer you did the dismount on (stoppend encfs). As soon as you unmount, the encfs view of files disappears and the underlying directory is now empty. This is also true if you ever start the sync program without encfs running.
If
there are any files in the directory underlying the mount point, encfs
--reverse will complain on startup about a non-emtpy mount point.
EncFSM won't do it. Under Linux, you’ll have to use it with a
fuse –nonempty option.
For this reason, it may be good to always
start encfs with the nonempty option:
encfs –reverse –o nonempty
~/cleartextfiles
~/cloudsync/encrypted
To
bring an
additional computer on-line to the synchronization, you need to have a
copy of
the xml file available on that computer in the clear text
directory. The xml file is in the
clear text
directory and not sync'd into the cloud from the first node, so you
could copy it there with other tools. Or, with synchronization
already running, put a copy of the xml file into the encrypted sync
directory (where it is required for any encfs forward nodes anyhow) and
when it appears on the second node, make a copy in the ~/cleartext directory on the
second computer.
Use the same command as on the first node and encfs will not ask you all the setup questions because it will find the xml file already present in the clear text directory.
encfs
–reverse –o nonempty ~/cleartextfiles ~/cloudsync/encrypted
At
this point,
you should be able to modify the ~/cleartextfiles
directory contents
and the
change will first propagate into the encfs directory
~/cloudsync/encrypted and
then up to the cloud and then down to the ~/cloudsync directory on the
other
computers, and then onto another computer’s virtual encrypted drive and
encfs
will store the real clear text change in the ~/cleartextfiles directory.
Based on the exact cryptologic initialization vector options you chose for encfs (see the man pages in the references below), decoding files may not work unless you use identical paths on all computers. This is because depending on what options you select, the encryption may depend on the full pathname to the file and other external factors.
I’m not sure
why the encfs man pages indicate you need to use the environment
variable
ENCFS6_CONFIG to recover data from the cloud. As explained above, it is
not necessary if you put the xml file where expected.
However, you can put the xml file anywhere and
use an environment variable. Using the
variable is
not allowed with reverse operations.
ENCFS6_CONFIG=/somewhere_else/.encfs6.xml
encfs ~/cloudsync/encrypted
~/cleartextfiles
With the ENCFS6_CONFIG variable pointing to different xml files, this allows access to selective subsets of files intermingled in a single encrypted real directory. Other encrypted files or miscellaneous files may be intermingled into the real encryted directory, but will not be decoded unless consistent with the xml file and password used for that bundle of files. This allows all sorts of encrypted files mixed up with each other, with different passwords, which makes it harder for the bad guys (and you as admin). See the encfs --anypass option.
Incidentally, this is a way
to distribute an encrypted set of files to a wide audience, while
allowing only some people to read some of the files. When
intermingled, all the encrypted files will be decryptable only when
using the xml file that was used to encrypt them. Each xml file
you create and use allows decryption of a unique subset of all the
encrypted files.
The skeleton of this document was originally created using AbiWord under a Gnome desktop. It was subsequently edited by Konquerer to become the web page you are reading. Last updated February 2017. The best way to get hold of me is via email.