Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] eCryptfs Support #13

Open
CurtisLeeBolin opened this issue Mar 10, 2015 · 14 comments
Open

[Feature Request] eCryptfs Support #13

CurtisLeeBolin opened this issue Mar 10, 2015 · 14 comments

Comments

@CurtisLeeBolin
Copy link

I understand eCryptfs support is a huge request, but if no one asks, it doesn't have a chance. I also understand the project might not be at a point it could take on such a request.

The biggest use case I have found for eCryptfs is it works on a USB flash drive with a FAT32 file system. I can have encrypted and non-encrypted files on the same file system. I am not stuck with a fully encrypted drive. I can still plug my flash drive into consumer products like a copier and save scanned documents to the flash drive. Who really wants to carry 2 flash drives around, one encrypted, one not? Since MS Windows has the forced limitation on USB flash drives that only the first partition can be mounted, 2 partitions (one encrypted, one not) is out of the question. Even it that was possible, I would be allocating a specific amount of space for encrypted and not, instead of them sharing the same storage capacity.

Please give this real consideration.

@t-d-k
Copy link
Owner

t-d-k commented Mar 11, 2015

This has been asked for before. There are already programs for windows that can encrypt individual files, and DoxBox can be used with a file-based Box.
Using up the same amount of space regardless of how much is encrypted is a feature, because it means no-one can tell the amount of encrypted data.
So, I'm sorry, but I won't be implementing this; although if someone else did I could accept the patch.

@t-d-k t-d-k added the wont fix label Mar 16, 2015
@linux-modder
Copy link
Collaborator

Seconding the denial as ecryptfs is not considered a secure method anymore (short of bootstrapping gcrypt and mcrypt on top

@Redsandro
Copy link

EcryptFS is a hugely popular defacto file-based encryption system used in many linux products. Ubuntu encrypts your home directory by default with EcryptFS. What do you mean not considered a secure method? I haven't heard such a claim, please provide a source.

Secondly, a large group of users are solely interested in a Windows program that can read Linux encryption.

For disk-based encryption, the standard is LUKS(1). For file-based encryption, the standard is EcryptFS(2). Right now, LibreCrypt is the only Windows tool that does (1). Nothing does (2). If you do both, you got yourself a popular go-to tool.

I think a read-only experimental feature would be popular.

@jdevora
Copy link

jdevora commented Jun 8, 2015

linux'modder: Are you sure you are mistaking it with the fuse based EncFS (http://en.wikipedia.org/wiki/EncFS) that have been dormant for many years ?

http://en.wikipedia.org/wiki/ECryptfs on the contrary, is active and is included in the Linux kernel

@linux-modder
Copy link
Collaborator

I was sorry, I use ECryptfs myself and will be working to get full support
in librecrypt for it yes

Corey W Sheldon

Freelance IT Consultant, Multi-Discipline Tutor(p) 310.909.7672

pub 3072D/718BF597
http://pgp.mit.edu/pks/lookup?op=get&search=0xE958C5D6718BF597 2014-12-08
Key fingerprint = 2930 99EB 083D D332 0752 88C4 E958 C5D6 718B F597

uid Corey Sheldon (Fedora Key) sheldon.corey@gmail.com

On Mon, Jun 8, 2015 at 11:06 AM, JuanDavi Evora Hanggi <
notifications@github.com> wrote:

linux'modder: Are you sure you are mistaking it with the fuse based EncFS (
http://en.wikipedia.org/wiki/EncFS) that have been dormant for many years
?

http://en.wikipedia.org/wiki/ECryptfs on the contrary, is active and is
included in the Linux kernel


Reply to this email directly or view it on GitHub
#13 (comment).

@Redsandro
Copy link

That sounds positive. Is it too early to get rid of that wontfix label? 😉

@linux-modder
Copy link
Collaborator

I'M cool with yanking the wont fix bu im out of office today and tomorrow
t-d-k could you possibly do that
On Jun 8, 2015 8:42 PM, "Sander AKA Redsandro" notifications@github.com
wrote:

That sounds positive. Is it too early to get rid of that wontfix label? [image:
😉]


Reply to this email directly or view it on GitHub
#13 (comment).

@Redsandro
Copy link

Don't worry, the label is trivial. The news is good tho!

@linux-modder
Copy link
Collaborator

I will try to get on intregration late this week
On Jun 9, 2015 12:48 PM, "Sander AKA Redsandro" notifications@github.com
wrote:

Don't worry, the label is trivial. The news is good tho!


Reply to this email directly or view it on GitHub
#13 (comment).

@alexforencich
Copy link

Why not use encfs and http://encfsmp.sourceforge.net/ ?

@Redsandro
Copy link

Because no one uses encfs and there is no reason to support it.

Contrary to ecryptfs, which is the default encryption file system in Ubuntu/Arch/Mint/Debian, so basically 95% of the Linux desktop market share would find that their encrypted drives become readable from within Windows if LibreCrypt would support this.

@CurtisLeeBolin
Copy link
Author

@alexforencich, I was discouraged from using encfs due to this report[1], but thank you for trying to find a solution for me.

[1]https://defuse.ca/audits/encfs.htm

@alexforencich
Copy link

My point is that encfsmp supports mounting encfs on windows and MAC. Besides, I prefer encfs to ecryptfs as encfs works with fuse so doesn't require root for mounting and unmounting, supports reverse mounting which is useful for backups via rsync, and does not add 8k to every single file.

@CurtisLeeBolin
Copy link
Author

FUSE is another reason I have avoided it. FUSE seems to have an inherent problem of ridiculous overhead. With ecryptfs I am getting identical IO rates as with the filesystem hosting the ecryptfs. @alexforencich, I do appreciate your suggestion.

@t-d-k t-d-k removed the wont fix label Jul 6, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants