- Encfs Macos Brew
- Encfs For Mac Os
- Encfs For Mac Download
- Encfs For Macbook Air
- Encfs For Mac Computers
- Encfs For Mac Catalina
- Encfs Mac Os Catalina
Mac OS X comes with FileVault, so why use EncFS instead? Well, FileVault has a few drawbacks that are summed up here. Personally I also like that with EncFS the encrypted files are stored in the filesystem as normal, you get the ability to use different encryption on different parts of the filesystem, and backup is straightforward.
(Note: This article was originally posted on my old Wikidot site on 2010-11-14)
Mac OS X comes with FileVault, so why use EncFS instead? Well, FileVault has a few drawbacks that are summed up here. Personally I also like that with EncFS the encrypted files are stored in the filesystem as normal, you get the ability to use different encryption on different parts of the filesystem, and backup is straightforward.
- TrueCrypt is not exactly 'Open Source', but the source is available. See the reviews to.
- Aug 04, 2011 I tried folders initialized with EncFS 1.5.x and 1.7.x.Also, after creating a new encrypted folder via the plugin (as described above), it complains about missing EncFS in the rawPath.Please fix, really need this for our Mac users ?.
- Jun 03, 2016 The only troublesome thing about EncFS is that it is command line-based and requires the use of terminal (or command prompt) to manually mount the encrypted folder. EncFSGui is a simple wrapper tool for Mac OS X that allows you to easily create or automate the mounting of an encrypted folder via a GUI window. It makes the whole mounting.
Requirements
EncFS requires FUSE so either install MacFUSE or install the MacPorts package. Next install EncFS itself. The easy option is the MacPorts package. Advanced users can download the source and compile their own if they want the very latest version, a custom install path, and/or a custom build.
Goal
The goal is to mount encrypted directories on login and unmount them on logout. The whole process should be completely transparent to the user and there are several ways to achieve this. One of them is to use login/logout hooks as documented here.
That is a nice solution, but in order for the keychain password to be accessible when the hook processes execute it must be placed in a public keychain. The reason is that the user’s private keychain isn’t unlocked yet at that point. I wanted a solution where the password was administered by the user and stored in his private keychain. I also wanted any scripts to be stored and executed in userspace.
Solution
First we create the encrypted directory. Make a directory where the encrypted files will be stored, and one which will be the mount point in which the decrypted versions of the files will appear. Then run the
encfs
command and follow the instructions.Encfs Macos Brew
To solve the login/logout problem I created a script which handles both. It executes upon login and mounts the encrypted directories with a password from the user’s keychain. The script then goes to sleep. When the user logs out the sleeping script gets a SIGTERM (15) signal which is intercepted. The script then unmounts the encrypted directories, performs cleanup, and exits.
Here is the script which I put in
~/bin/encfsd.sh
:The cleanup function is called when the script gets signalled to terminate. It kills the sleep process running in the background, unmounts the encrypted directory, and exits.
After the function body is the trap command which tells the script to call the cleanup function when it receives signal 1, 2, 3, 6 or 15. The last signal, 15, is the default quit signal SIGTERM (check
man signal
for the rest).Next comes the
security
command which retrieves the password from the user’s keychain. The redirect is necessary since the password is printed to stderr. The output with the password is then sent to the cut command where the password is isolated. It is then sent as input to the encfs
command.After that the script goes to sleep.
To automatically start the script on login it is installed as a Launch Agent. Here are the contents of my
~/Library/LaunchAgents/localhost.encfsd.plist
:It basically says the system should run the
encfsd.sh
script once, run it as a background process, and run when the agent loads.With the scripts in place the user should now have automatic mount of encrypted directories on login, and they should unmount on logout.
Developer(s) | Valient Gough |
---|---|
Stable release | |
Repository | |
Operating system | Linux, FreeBSD, macOS,[2]Windows ('encfs4win' port)[3] (also Safe, an alternative macOS, Windows port) and Android apps |
Type | filesystem, encryption |
License | LGPL |
Website | EncFS home |
EncFS is a Free (LGPL) FUSE-based cryptographic filesystem. It transparently encrypts files, using an arbitrary directory as storage for the encrypted files.[4][5]
Two directories are involved in mounting an EncFS filesystem: the source directory, and the mountpoint. Each file in the mountpoint has a specific file in the source directory that corresponds to it. The file in the mountpoint provides the unencrypted view of the one in the source directory. Filenames are encrypted in the source directory.
Files are encrypted using a volume key, which is stored either within or outside the encrypted source directory.[6] A password is used to decrypt this key.
Common uses[edit]
- In Linux, allows encryption of home folders as an alternative to eCryptfs.
- Allows encryption of files and folders saved to cloud storage (Dropbox, Google Drive, OneDrive, etc.).
- Allows portable encryption of file folders on removable disks.
- Available as a cross-platform folder encryption mechanism.
- Increases storage security by adding two-factor authentication (2FA). When the EncFS volume key is stored outside the encrypted source directory and into a physically separated location from the actual encrypted data, it significantly increases security by adding a two-factor authentication (2FA). For example, EncFS is able to store each unique volume key anywhere else than the actual encrypted data, such as on a USB flash drive, network mount, optical disc or cloud.[6] In addition to that a password could be required to decrypt this volume key.
Advantages[edit]
EncFS offers several advantages over other disk encryption software simply because each file is stored individually as an encrypted file elsewhere in the host's directory tree.
Cross-platform[edit]
EncFS is available on multiple platforms, whereas eCryptfs is tied to the Linux kernel
Bitrot support[edit]
EncFS implements bitrot detection on top of any underlying filesystem
Scalable storage[edit]
EncFS has no 'volumes' that occupy a fixed size — encrypted directories grow and shrink as more files are added to or removed from the mountpoint
Normal file server[edit]
EncFS's encrypted directory can be located on a normal file server (via NFS, SSHFS, etc.) and can be mirrored and backed up efficiently with normal file-system tools, such as Rsync
Different physical devices[edit]
It is possible for some directories on the mountpoint to exist on different physical devices, if a filesystem is mounted over one of the sub-directories in the source directory
Faster backup[edit]
Backup utilities can back up only the files that have changed in the source directory (file synchronisation, cloud storage)
Reduced corruption[edit]
![Macbook Macbook](/uploads/1/2/4/6/124616360/992739414.png)
Corruption of data is more isolated. Corruption of filedata is local to a single file, and data corruption of the filesystem can be corrected with a reliable filesystem repair utility like fsck. Some whole-disk encryption systems lack one or both of these attributes.
Optimizations[edit]
Since file modifications shine through to the underlying file system, various optimizations by the operating system are still possible unlike with full-disk encryption. For example, passing information about released space (TRIM) can improve performance of SSD drives. But this is also supported with dm-crypt.
Random file access[edit]
Files can be accessed at random. You can, for example, skip to the middle of a very large encrypted video without decrypting the whole file.
Disadvantages[edit]
There are some drawbacks to using EncFS.
Compatibility[edit]
Mounted EncFS directories share the same features and restrictions as the filesystem containing the source directory.
No support for very long filenames[edit]
Due to encryption, the filenames for encrypted files produced by EncFS are longer than the original filenames. Therefore, filenames whose length is close to the maximum supported by the filesystem cannot be stored by EncFS, since they will exceed the length limit after encryption. Most filesystems limit filenames to 255 bytes; in that case, EncFS only supports filenames up to 190 bytes.[7][8]
General security concerns[edit]
Anyone having access to the source directory is able to see how many files are in the encrypted filesystem, what permissions they have, their approximate size, and the last time they were accessed or modified, though the file names and file data are encrypted.[9]
Encfs For Mac Os
EncFS 1.7 security concerns[edit]
A paid security audit was conducted in February 2014, which revealed several potential vulnerabilities. It concludes:[10]
EncFS is probably safe as long as the adversary only gets one copy of the ciphertext and nothing more. EncFS is not safe if the adversary has the opportunity to see two or more snapshots of the ciphertext at different times. EncFS attempts to protect files from malicious modification, but there are serious problems with this feature.
EncFS 1.8 security concerns[edit]
The announcement of EncFS 1.8 included several underlying design changes, acknowledging the security concerns raised in the previous audit. However, certain concerns still remain regarding those vulnerabilities.[11]
Filesystem options[edit]
When creating a new EncFS volume, several different options are available to customize the filesystem to suit various needs.
Cipher algorithm[edit]
EncFS uses whatever ciphers it is able to locate in various encryption libraries on the system. Blowfish and AES are typically available.
The cipher key length (keySize) can be selected for ciphers that support variable key lengths.
Block size[edit]
Each file is encrypted in blocks, and this option controls what size those blocks are. Each time a single byte is read the entire block it is contained in must be decrypted. Likewise, for each write the block must be decrypted, altered, and re-encrypted.
The default block size of 1024 is sufficient for most purposes.
Encfs For Mac Download
Filename encoding[edit]
Filenames in the source directory can be plain or encrypted in block or stream mode. Block mode obscures the filename length somewhat, while stream mode keeps them as short as possible, which might save space on the source directory's filesystem depending on how that filesystem manages the directory tree.
Filename IV chaining[edit]
When enabled, the initialization vector for filename encryption is derived from the file's parent directories, causing two files with the same name — but in different directories — to have different encrypted filenames.
If a directory is renamed, all files and directories contained therein will need to have their encrypted filenames re-encrypted, which can be an expensive operation. This option should be disabled if heavily populated directories will be renamed often.
![Macos Macos](https://habrastorage.org/storage/7fe02f6e/bf382f1d/bfc3b8e5/cf00ea25.jpg)
Per-file IV initialization vector[edit]
When enabled, each file is encrypted with a random 8-byte initialization vector, which is stored within the encrypted file in the source directory. If this option is disabled, each file is encrypted with the same initialization vector, which can make the volume key easier to break.
Enabling this option makes the filesystem more secure at the cost of an additional 8 bytes per file.
External IV chaining[edit]
Causes the file data initialization vector to be derived from the filename's initialization vector chain. The same data will be encrypted differently given a different filename or directory.
Consequently, renaming a file when this mode is enabled requires that either the file's random initialization vector be offset by the change in the filename initialization vector chain, or the data be re-encoded. The authors of EncFS have chosen the former route as it is considerably faster, especially for large files.
Filename to IV header chaining[edit]
Makes encoding depend on the full pathname. So renaming or moving means reencoding. Hardlinks are not supported.
Encfs For Macbook Air
Block MAC headers[edit]
Stores a checksum with each encrypted block, causing corruption or modification of the encrypted files to be detected by EncFS. The checksum (blockMACBytes) is 8 bytes, and optionally up to 8 additional bytes of random data (blockMACRandBytes) can be added to each block to prevent two blocks with the same unencrypted data from having the same checksum. This option creates a large amount of CPU overhead, as each block's checksum must be calculated when data is read (to verify integrity) or written (to update the checksum).
Secondary volumes[edit]
EncFS supports a somewhat primitive form of secondary volumes, that is, a single source directory offering different files given different passwords.
Encfs For Mac Computers
If EncFS is unable to decrypt a file with the volume key, it is ignored. If EncFS is forced to ignore an invalid password entry, the volume key will decode differently, and hence files will be encrypted and decrypted with a different key. This will present two different encrypted volumes given different passwords.
However, it is possible that two filenames on two different secondary volumes will be encrypted to the same filename. In this case, any other file will be overwritten with a new file being created. Note that this refers only to the encrypted filenames, not the unencrypted filenames. This danger can be averted by creating one directory per secondary volume and storing files in the only visible directory after a secondary volume is mounted.
Also, if the password is changed, the volume key will be re-encoded with the new password. This will cause secondary filesystems to vanish, as the volume key will no longer incorrectly decode to the same key for a given secondary password. If the primary password is changed back, the secondary filesystems will become available again.
Encfs For Mac Catalina
The EncFS author does not support this technique.
See also[edit]
References[edit]
Encfs Mac Os Catalina
- ^'Releases - vgough/encfs'. Retrieved 11 June 2018 – via GitHub.
- ^'Valient Gough'. Valient Gough. Retrieved 23 April 2018.
- ^'encfs4win - an experimental project of porting encfs to the Windows world'. Retrieved 29 November 2013.
- ^Falko, Timme (2017-01-14). 'How to Encrypt your Data with EncFS on Debian 8 (Jessie)'. The Linux Foundation. Retrieved 2017-04-13.
- ^Falko, Timme (2016-05-06). 'Encrypt your Data with EncFS on Ubuntu 16.04'. The Linux Foundation. Retrieved 2017-04-13.
- ^ abGough, Valient (2016-12-26). 'ENVIRONMENT VARIABLES'. GitHub. Retrieved 2017-05-07.
- ^'Issue #7 - alternative filename storage for very long filenames'. github.com. 2014-08-22. Retrieved 2016-01-27.
Long filenames can exceed the filesystem limits after encryption & encoding.
- ^'Manpage for enfs.1'. manpages.ubuntu.com. Ubuntu. Archived from the original on 2016-02-03. Retrieved 2016-01-27.
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 than plaintext filenames.
- ^'EncFS Directory Encryption Notes'.
- ^'EncFS Security Audit'.
- ^'EncFS 1.8 Announcement'.
External links[edit]
Retrieved from 'https://en.wikipedia.org/w/index.php?title=EncFS&oldid=951848464'