File-level encryption alternatives to EncFS on OSX?
June 13, 2010 9:14 PM Subscribe
The MacFusion project is, for all intents and purposes, dormant. MacFUSE is nearly so. EncFS for OSX appears to have issues with later builds. What other alternatives are there for file-level (as opposed to block- or filesystem-level) encryption in OSX?
Again, I don't need assistance with filesystem or block encryption - I'm aware of Disk Utility's capabilities. I need transparent file-level encryption, preferably something that can be auto-enabled on login, for OSX. What alternatives to EncFS are out there?
Again, I don't need assistance with filesystem or block encryption - I'm aware of Disk Utility's capabilities. I need transparent file-level encryption, preferably something that can be auto-enabled on login, for OSX. What alternatives to EncFS are out there?
Response by poster: Filevault is fs/block encryption - that is, it encrypts a whole filesystem and must be mounted and unmounted. It won't work for my specific use. I need something that is file-based, like EncFS.
posted by aberrant at 9:53 PM on June 13, 2010
posted by aberrant at 9:53 PM on June 13, 2010
No, FileVault is not encrypting a whole filesystem. It encrypts your home folder, and is activated when you log in to your account.
posted by Blazecock Pileon at 10:17 PM on June 13, 2010
posted by Blazecock Pileon at 10:17 PM on June 13, 2010
Response by poster: I understand how FileVault can/does work. It does not provide file-level encryption. It provides filesystem-level encryption, wherein a virtual or physical filesystem is encrypted in its entirety, as opposed to opportunistically encrypting individual files, which is (more or less - we can get into what happens over FUSE offline) what EncFS does.
In any case, FileVault won't do what I need. Are there alternatives to EncFS that provide file-level encryption?
posted by aberrant at 10:30 PM on June 13, 2010
In any case, FileVault won't do what I need. Are there alternatives to EncFS that provide file-level encryption?
posted by aberrant at 10:30 PM on June 13, 2010
Fink has a package for EncFS 1.5. I haven't tested it, but my experience has been that if it's in their tree then it compiles and works. MacPorts also has one, although I'm not as familiar with that system.
So if you're up to the technical challenge, I'd install one of those two systems and use its version of EncFS.
As for the longevity of MacFUSE, I get the feeling that it's stagnated because it's become rather mature. VMware and Panic are the two big developers I know who use it with their products, so I doubt they'll let it become obsolete. The lack of a 64bit version is concerning, but I bet someone will take up the task when it becomes necessary.
posted by sbutler at 12:12 AM on June 14, 2010
So if you're up to the technical challenge, I'd install one of those two systems and use its version of EncFS.
As for the longevity of MacFUSE, I get the feeling that it's stagnated because it's become rather mature. VMware and Panic are the two big developers I know who use it with their products, so I doubt they'll let it become obsolete. The lack of a 64bit version is concerning, but I bet someone will take up the task when it becomes necessary.
posted by sbutler at 12:12 AM on June 14, 2010
File-level encryption seems fishy to me. Maybe you want to start by stating your use case (motive) so we can understand your needs better.
File-level encryption seems fishy because it has known conceptual issues that block-level or device-level encryption are intended to solve.
Think about key management for instance: which key do you plan to use? Choose one key for all files, and your cryptographic strength is weakened. One key per file, and you quickly have hundreds of keys to manage.
Then many applications will perform a save cycles by first renaming a file to .bak, then writing the new content to a new file. Or they might copy the file to .bak. Also Time Machine could kick in and archive multiple versions of your files. Would you want all these files to be encrypted? (With which key?) In many of these cases case, you end up with multiple versions of the file with similar content but the same encryption key, which again greatly weakens cryptographic strength.
Also unless you waste space file-level encryption leaks information about file size.
posted by knz at 12:12 AM on June 14, 2010
File-level encryption seems fishy because it has known conceptual issues that block-level or device-level encryption are intended to solve.
Think about key management for instance: which key do you plan to use? Choose one key for all files, and your cryptographic strength is weakened. One key per file, and you quickly have hundreds of keys to manage.
Then many applications will perform a save cycles by first renaming a file to .bak, then writing the new content to a new file. Or they might copy the file to .bak. Also Time Machine could kick in and archive multiple versions of your files. Would you want all these files to be encrypted? (With which key?) In many of these cases case, you end up with multiple versions of the file with similar content but the same encryption key, which again greatly weakens cryptographic strength.
Also unless you waste space file-level encryption leaks information about file size.
posted by knz at 12:12 AM on June 14, 2010
Response by poster: I'll state my use case and then mark this as "best answer" because I found what I was looking for.
Dropbox does not have a facility for performing user-based encryption. While they claim to encrypt your files and not to have access to the keys, I want more assurance that my files are secure from most but my eyes.
Many people have used TrueCrypt or FileVault to encrypt files in their dropbox, but the huge disadvantage is that because TC and FV are filesystem-level encryptors, they have to be unmounted in one place before they can be mounted in another. I use dropbox concurrently across three machines and must have access to the encrypted information at any time on all of them.
EncFS and other file-level encryption options do not have that limitation. Yes, they leak information about file size and heirarchy, but that's "OK" for this use case. As to the keys, a single key provides - in some cases - a way to do known plaintext attacks, but there's little else even a moderately-skilled attacker can do.
The EncFS solution, while it worked, was a bit of a kludge: EncFS over MacFuse managed by MacFusion, and a problem with any one of those layers caused the whole thing to blow up. Having two - possibly three - of the layers remain stagnant for so long was (and is) a big concern.
Enter SecurStick, which is what I found late last night. It provides transparent file-level encryption via WebDAV and, aside from a caching issue in Windows (which I don't use), appears to meet my requirements. I'll be poring through the source in the next week or so to make sure there are no dumb implementation decisions, but so far it's the most promising viable candidate out there.
So, there's my use case - I hope you'll agree that FS-level encryption is not an appropriate option, and that the disadvantages of using file-level encryption are not applicable here.
posted by aberrant at 6:32 AM on June 14, 2010
Dropbox does not have a facility for performing user-based encryption. While they claim to encrypt your files and not to have access to the keys, I want more assurance that my files are secure from most but my eyes.
Many people have used TrueCrypt or FileVault to encrypt files in their dropbox, but the huge disadvantage is that because TC and FV are filesystem-level encryptors, they have to be unmounted in one place before they can be mounted in another. I use dropbox concurrently across three machines and must have access to the encrypted information at any time on all of them.
EncFS and other file-level encryption options do not have that limitation. Yes, they leak information about file size and heirarchy, but that's "OK" for this use case. As to the keys, a single key provides - in some cases - a way to do known plaintext attacks, but there's little else even a moderately-skilled attacker can do.
The EncFS solution, while it worked, was a bit of a kludge: EncFS over MacFuse managed by MacFusion, and a problem with any one of those layers caused the whole thing to blow up. Having two - possibly three - of the layers remain stagnant for so long was (and is) a big concern.
Enter SecurStick, which is what I found late last night. It provides transparent file-level encryption via WebDAV and, aside from a caching issue in Windows (which I don't use), appears to meet my requirements. I'll be poring through the source in the next week or so to make sure there are no dumb implementation decisions, but so far it's the most promising viable candidate out there.
So, there's my use case - I hope you'll agree that FS-level encryption is not an appropriate option, and that the disadvantages of using file-level encryption are not applicable here.
posted by aberrant at 6:32 AM on June 14, 2010
Response by poster: (unmarked as best answer - as it turns out, there's a ton of undocumented functionality in this closed-source app and there's just too much risk that something unwanted is happening behind the scenes.)
posted by aberrant at 7:07 AM on June 15, 2010
posted by aberrant at 7:07 AM on June 15, 2010
Is Dropbox a hard requirement, or could you substitute another cloud-based storage provider?
SpiderOak is very similar to Dropbox in its functionality, but say they use client-side encryption with no server-side key storage. See their Engineering Notes for details.
This is certainly much more security than what Dropbox is stating they provide. I haven't seen an independent crypto audit, nor have they released source code for the client, although they say it's in their plans at some point soon.
posted by dttocs at 6:39 AM on June 16, 2010
SpiderOak is very similar to Dropbox in its functionality, but say they use client-side encryption with no server-side key storage. See their Engineering Notes for details.
This is certainly much more security than what Dropbox is stating they provide. I haven't seen an independent crypto audit, nor have they released source code for the client, although they say it's in their plans at some point soon.
posted by dttocs at 6:39 AM on June 16, 2010
This thread is closed to new comments.
posted by Blazecock Pileon at 9:36 PM on June 13, 2010