encfs - mounts or creates an encrypted virtual filesystem
encfs [--version] [-s] [-f] [-v|--verbose] [-i MINUTES|--idle=MINUTES] [--extpass=program] [-S|--stdinpass] [--anykey] [--forcedecode] [-d|--fuse-debug] [--public] [--no-default-flags] rootdir mountPoint [-- [Fuse Mount Options]]
encfs creates a virtual encrypted filesystem which stores encrypted data in the rootdir directory and makes the unencrypted data visible at the mountPoint directory. The user must supply a password which is used to (indirectly) encrypt both filenames and file contents.
If encfs is unable to find a supported filesystem at the specified rootdir, then the user will be asked if they wish to create a new encrypted filesystem at the specified location. Options will be presented to the user allowing some control over the algorithms to use. As EncFS matures, there may be an increasing number of choices.
Note that if the primary password is changed (using encfsctl), the other passwords will not be usable unless the primary password is set back to what it was, as the other passwords rely on an invalid decoding of the volume key, which will not remain the same if the primary password is changed.
Warning: Use this option at your own risk.
EncFS takes everything returned from the program to be the password, except for a trailing newline (\n) which will be removed.
For example, specifying --extpass=/usr/lib/ssh/ssh-askpass will cause EncFS to use ssh's password prompt program.
Note that you should make sure the filesystem and mount points exist first. Otherwise encfs will prompt for the filesystem creation options, which may interfere with your script.
Warning: In order for this to work, encfs must be run as root -- otherwise it will not have the ability to change ownership of files. I recommend that you instead investigate if the fuse allow_other option can be used to do what you want before considering the use of --public.
The following command lines produce the same result:
encfs raw crypt
encfs --no-default-flags raw crypt -- -o use_ino,default_permissions
Create a new encrypted filesystem. Store the raw (encrypted) data in ``~/.crypt'' , and make the unencrypted data visible in ``~/crypt''. Both directories are in the home directory in this example. This example shows the full output of encfs as it asks the user if they wish to create the filesystem:
% encfs ~/.crypt ~/crypt
Directory "/home/me/.crypt" does not exist, create (y,n)?y
Directory "/home/me/crypt" does not exist, create (y,n)?y
Creating new encrypted volume.
Please choose from one of the following options:
enter "x" for expert configuration mode,
enter "p" for pre-configured paranoia mode,
anything else, or an empty line will select standard mode.
?>
Standard configuration selected.
Using cipher Blowfish, key size 160, block size 512
New Password: <password entered here>
Verify: <password entered here>
The filesystem is now mounted and visible in ~/crypt. If files are created there, they can be seen in encrypted form in ~/.crypt. To unmount the filesystem, use fusermount with the -u (unmount) option:
% fusermount -u ~/crypt
Another example. To mount the same filesystem, but have fusermount name the mount point '/dev/foo' (as shown in df and other tools which read /etc/mtab), and also request kernel-level caching of file data (which are both special arguments to fusermount):
% encfs ~/.crypt ~/crypt -- -n /dev/foo -c
Or, if you find strange behavior under some particular program when working in an encrypted filesystem, it may be helpful to run in verbose mode while reproducing the problem and send along the output with the problem report:
% encfs -v -f ~/.crypt ~/crypt 2> encfs-report.txt
In order to avoid leaking sensitive information through the debugging channels, all warnings and debug messages (as output in verbose mode) contain only encrypted filenames. You can use the encfsctl program's decode function to decode filenames if desired.
EncFS is not a true filesystem. It does not deal with any of the actual storage or maintenance of files. It simply translates requests (encrypting or decrypting as necessary) and passes the requests through to the underlying host filesystem. Therefor any limitations of the host filesystem will likely be inherited by EncFS (or possibly be further limited).
One such limitation is filename length. If your underlying filesystem limits you to N characters in a filename, then EncFS will limit you to approximately 3*(N-2)/4. For example if the host filesystem limits to 256 characters, then EncFS will be limited to 190 character filenames. This is because encrypted filenames are always longer then plaintext filenames.
When EncFS is given a root directory which does not contain an existing EncFS filesystem, it will give the option to create one. Note that options can only be set at filesystem creation time. There is no support for modifying a filesystem's options in-place.
If you want to upgrade a filesystem to use newer features, then you need to create a new filesystem and mount both the old filesystem and new filesystem at the same time and copy the old to the new.
Multiple instances of encfs can be run at the same time, including different versions of encfs, as long as they are compatible with the current FUSE module on your system.
A choice is provided for two pre-configured settings ('standard' and 'paranoia'), along with an expert configuration mode.
Standard mode uses the following settings: Cipher: Blowfish Key Size: 160 bits Filesystem Block Size: 512 bytes Filename Encoding: Block encoding with IV chaining Unique initialization vector file headers
Paranoia mode uses the following settings: Cipher: AES Key Size: 256 bits Filesystem Block Size: 512 bytes Filename Encoding: Block encoding with IV chaining Unique initialization vector file headers Message Authentication Code block headers External IV Chaining
In the expert / manual configuration mode, each of the above options is configurable. Here is a list of current options with some notes about what they mean:
Blowfish is an 8 byte cipher - encoding 8 bytes at a time. AES is a 16 byte cipher.
Having larger block sizes reduces the overhead of EncFS a little, but it can also add overhead if your programs read small parts of files. In order to read a single byte from a file, the entire block that contains that byte must be read and decoded, so a large block size adds overhead to small requests. With write calls it is even worse, as a block must be read and decoded, the change applied and the block encoded and written back out.
The default is 512 bytes as of version 1.0. It was hard coded to 64 bytes in version 0.x, which was not as efficient as the current setting for general usage.
The advantage of block encoding mode is that filename lenths all come out as a multiple of the cipher block size. This means that someone looking at your encrypted data can't tell as much about the length of your filenames. It is on by default, as it takes a similar amount of time to using the stream cipher. However stream cipher mode may be useful if you want shorter encrypted filenames for some reason.
Prior to version 1.1, only stream encoding was supported.
With initialization vector chaining, each directory gets its own initialization vector. So ``a/foo'' and ``b/foo'' will have completely different encoded names for ``foo''. This features has almost no performance impact (for most operations), and so is the default in all modes.
Note: One significant exception is directory renames. Since the initialization vector for filename encoding depends on the directory path, any rename requires re-encoding every filename in the tree of the directory being changed. If there are thousands of files, then EncFS will have to do thousands of renames. It may also be possible that EncFS will come across a file that it can't decode or doesn't have permission to move during the rename operation, in which case it will attempt to undo any changes it made up to that point and the rename will fail.
With per-file initialization vectors, each file gets its own 64bit random initialization vector, so that each file is encrypted in a different way.
This option is enabled by default.
When this option is enabled, the per-file initialization vector is encoded using the initialization vector derived from the filename initialization vector chaining code. This means that the data in a file becomes tied to the filename. If an encrypted file is renamed outside of encfs, it will no longer be decodable within encfs. Note that unless Block MAC headers are enabled, the decoding error will not be detected and will result in reading random looking data.
There is a cost associated with this. When External IV Chaining is enabled, hard links will not be allowed within the filesystem, as there would be no way to properly decode two different filenames pointing to the same data.
Also, renaming a file requires modifying the file header. So renames will only be allowed when the user has write access to the file.
Because of these limits, this option is disabled by default for standard mode (and enabled by default for paranoia mode).
This adds substantial overhead (default being 8 bytes per filesystem block), plus computational overhead, and is not enabled by default except in paranoia mode.
When this is not enabled and if EncFS is asked to read modified or corrupted data, it will have no way to verify that the decoded data is what was originally encoded.
The primary goal of EncFS is to protect data off-line. That is, provide a convenient way of storing files in a way that will frustrate any attempt to read them if the files are later intercepted.
Some algorithms in EncFS are also meant to frustrate on-line attacks where an attacker is assumed to be able to modify the files.
The most intrusive attacks, where an attacker has complete control of the user's machine (and can therefor modify EncFS, or FUSE, or the kernel itself) are not guarded against. Do not assume that encrypted files will protect your sensitive data if you enter your password into a compromised computer. How you determine that the computer is safe to use is beyond the scope of this documentation.
That said, here are some example attacks and data gathering techniques on the filesystem contents along with the algorithms EncFS supports to thwart them:
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Please refer to the ``COPYING'' file distributed with encfs for complete details.
EncFS was written by Valient Gough
encfsctl(1)