# ecryptfs from 2.6.19

## airon

Has anybody tried to use ecryptfs? As it's included in the 2.6.19 kernel, I decided to give it a try but with no luck. I enabled the required options in the kernel (for the key retention,...) and the ecryptfs. So, everything is compiled,...

Now for example, as root, I create to folders: /root/encrypted and /root/nonencrypted

I type: mount -t ecryptfs /root/nonencrypted /root/encrypted. It promts for a password, so I type it.

If I do: echo hello >> /root/encrypted then nothing is written in /root/nonencrypted. I don't know why. The file exists only in /root/encrypted and of course, as plain text.

If I type mount to list the mounted partitions, nothing make reference to ecryptfs and those folders.

I have the ecryptfs utils installed.

Any idea?

----------

## trace12

same Problem

sys-kernel/gentoo-sources-2.6.19-r2

sys-fs/ecryptfs-utils-7

----------

## Hypnos

Any luck/updates?

----------

## JoeUser

works fine for me.

sys-kernel/gentoo-sources-2.6.19-r4

sys-fs/ecryptfs-utils-7 (only change was modified ebuild in local overlay to add ~amd64 to keywords)

tested with:  

   mount -t ecryptfs /root/test/enc /root/test/unenc

output:

   Passphrase:  

   Verify Passphrase: 

   Attempting to mount with the following options:

     ecryptfs_sig=aa20c2d38cf280d5

   Mounted ecryptfs

relevant output from mount:

   /root/test/enc on /root/test/unenc type ecryptfs (rw,ecryptfs_sig=aa20c2d38cf280d5,)

then did the following to test:

   echo "blah blah blah" > /root/test/unenc/foo.bar

   ls -l /root/test/unenc/foo.bar

      -rw-r--r-- 1 root root 15 Jan 25 11:41 /root/test/unenc/foo.bar

   cat /root/test/unenc/foo.bar

      blah blah blah

   ls -l /root/test/enc/foo.bar

      -rw-r--r-- 1 root root 12288 Jan 25 11:41 /root/test/enc/foo.bar

   cat /root/test/enc/foo.bar

      all kinds of encrypted gibberish

In the kernel config I have "eCrypt filesystem layer support" built into the kernel rather then as a module.  Is yours a module?  If so, maybe the module failed to load?  Does it show up on the list when you do an lsmod?

----------

## Hypnos

How is the performance compared to the raw underlying filesystem?

----------

## JoeUser

hmm, not too bad actually.  i was using EncFS until just now  :Smile: 

dbench with only one process for the default 600 seconds came up with these numbers:

Raw Filesystem: Throughput 88.3486 MB/sec 1 procs

eCryptfs: Throughput 30.9959 MB/sec 1 procs

EncFS: Throughput 8.61068 MB/sec 1 procs

Time to move all the EncFS stuff over me thinks.

----------

## airon

I've upgraded to 2.6.19-r4 and it continues not working.

I've found something that could give a hint: doing a tail /var/log/messages I can see:

mount.ecryptfs: Your kernel does not support key module [openssl]

But, I think that I have all requested kernel settings set correctly. 

```

CONFIG_KEYS=y

CONFIG_BLK_DEV_CRYPTOLOOP=y

CONFIG_DM_CRYPT=m

CONFIG_ECRYPT_FS=y

# Cryptographic options

CONFIG_CRYPTO=y

CONFIG_CRYPTO_ALGAPI=y

CONFIG_CRYPTO_BLKCIPHER=y

CONFIG_CRYPTO_HASH=y

CONFIG_CRYPTO_MANAGER=y

CONFIG_CRYPTO_HMAC=y

# CONFIG_CRYPTO_NULL is not set

CONFIG_CRYPTO_MD4=y

CONFIG_CRYPTO_MD5=y

CONFIG_CRYPTO_SHA1=y

CONFIG_CRYPTO_SHA256=y

CONFIG_CRYPTO_SHA512=y

CONFIG_CRYPTO_WP512=y

CONFIG_CRYPTO_TGR192=y

CONFIG_CRYPTO_ECB=m

CONFIG_CRYPTO_CBC=y

CONFIG_CRYPTO_DES=y

CONFIG_CRYPTO_BLOWFISH=y

CONFIG_CRYPTO_TWOFISH=y

CONFIG_CRYPTO_TWOFISH_COMMON=y

CONFIG_CRYPTO_TWOFISH_586=y

CONFIG_CRYPTO_SERPENT=y

CONFIG_CRYPTO_AES=y

CONFIG_CRYPTO_AES_586=y

CONFIG_CRYPTO_CAST5=y

CONFIG_CRYPTO_CAST6=y

CONFIG_CRYPTO_TEA=y

CONFIG_CRYPTO_ARC4=y

CONFIG_CRYPTO_KHAZAD=y

CONFIG_CRYPTO_ANUBIS=y

CONFIG_CRYPTO_DEFLATE=y

CONFIG_CRYPTO_MICHAEL_MIC=y

# CONFIG_CRYPTO_CRC32C is not set

# CONFIG_CRYPTO_TEST is not set

# Hardware crypto devices

# CONFIG_CRYPTO_DEV_PADLOCK is not set

# Security options

CONFIG_SECURITY=y

# CONFIG_SECURITY_NETWORK is not set

CONFIG_SECURITY_CAPABILITIES=y

# CONFIG_SECURITY_ROOTPLUG is not set

```

----------

## JoeUser

 *airon wrote:*   

> mount.ecryptfs: Your kernel does not support key module [openssl]

 

I've seen that error too last month when I tried using public key based encryption with keys made from the little key manager that comes with ecryptfs or made from openssl but I didn't spent anytime looking into solving the problem.  Their website said they were planning advanced key management and gnupg keys support so I decided to stick with plain old pass phrases until then and eventually use my existing gpg keys and keychain.

Do you get that error with just simple pass phrases too?  Your original post that started this thread doesn't show the key option in the command so I assumed you weren't.

This might be helpful.  http://ecryptfs.sourceforge.net/ecryptfs-faq.html

Specifically the "Q. How can I find out which features are in my eCryptfs kernel module?"

```
# cat /sys/fs/ecryptfs/version_str

passphrase

pubkey

plaintext passthrough

metadata in extended attribute
```

I need to check that myself when I get home from work in a couple hours.  Maybe we're both missing an option in our kernel configs.  If we did and if I find it I'll post it here.

----------

## airon

Yes, I was trying just symple passphrases, for example:

```

~#  mount -t ecryptfs test/noenc test/enc

Passphrase: test

Verify Passphrase: test

~ #

```

So, after setting the passwords, the system doesn't report any error. The only place to see the error is in /var/log/messages, which is the error that I said above.

If I type mount to see the mounted elements, nothing makes reference to those folders (and of course, there aren't ecryptfs elements).

Curiously, when I check the features that are available for me I just get these:

```

$ cat /sys/fs/ecryptfs/version_str

passphrase

plaintext passthrough

```

That obviuosly can explain why my openssl throw that in the log. Very probably it has to be a problem with a missing setting in the kernel, but, I think that I have everything that ecryptfs requires in the faq. I have the same problem in two machines.

----------

## batistuta

 *airon wrote:*   

> I type: mount -t ecryptfs /root/nonencrypted /root/encrypted. It promts for a password, so I type it.
> 
> If I do: echo hello >> /root/encrypted then nothing is written in /root/nonencrypted. I don't know why. The file exists only in /root/encrypted and of course, as plain text.

 

I think you have it backwards. You should do

```
echo hello >> /root/nonencrypted/test.txt 
```

And then ecryptfs will encrypt the stuff and create the encrypted files in its encrypted form under /root/encrypted. You always deal with root/nonencrypted for transparent access.

----------

## airon

I think that I did it in the right direction, at least is what I understand from this piece of the text from the README file included in ecryptfs

 *Quote:*   

> 
> 
> MOUNT-WIDE PASSPHRASE
> 
> Create a new directory into which eCryptfs will write its encrypted
> ...

 

Anyways, I think that the problem is different here as what really fails is mount.ecryptfs, which, some how can't mount the fs.

----------

## JoeUser

I got home from work and checked "/sys/fs/ecryptfs/version_str". It's the same as yours.  Still works for me though.  The version of ecryptfs-utils in portage is a couple versions behind. I modifed the ebuild to install "ecryptfs-utils-9" but while doing that i realized it's probably not the userspace tools that's the problem, it's the kernel.  The latest version of that is "ecryptfs-20070111" but the website recommends using the new kernel rather then this package.  I was going to change the ebuild to install this but the new kernel is going to be released very soon.  It might be better to wait for it.

If you don't want to wait, you should be able to remove it from the kernel then build the kernel module from this package to get the newest version.  Maybe that will solve your problem?  Just building a kernel module shouldn't pollute your gentoo box too much because they generally don't install files in too many places.  You can still use portage to install the utils if you use a local overlay and copy the version 7 ebuild to version 9, strip the header out on the 3rd line and emerge with the --digest option.

This is what I did.  My local overlay is /usr/local/portage and is defined in make.conf.

```
mkdir -p /usr/local/portage/sys-fs/ecryptfs-utils

cp /usr/portage/sys-fs/ecryptfs-utils/ecryptfs-utils-7.ebuild /usr/local/portage/sys-fs/ecryptfs-utils/ecryptfs-utils-9.ebuild
```

then edit that ebuild file and change the "# $Header" line to:

```
# $Header: $
```

Changing the $Header line is pretty important.  It looks like a comment but it's really more then that.  If you don't change it then it'll still download and install version 7.

now just emerge it with the command:

```
emerge --digest =sys-fs/ecryptfs-utils-9
```

You need the --digest option here because the new ebuild in the overlay doesn't yet have a manifest file created for it.

That's it.  It'll download version 9 of the utils from sourceforge, install them and keep it managed by portage so there's no system pollution.  :Smile: 

Hopefully the new user space utils or the new kernel module will resolve your problem.

----------

## batistuta

 *airon wrote:*   

> I think that I did it in the right direction, at least is what I understand from this piece of the text from the README file included in ecryptfs

 

Sorry. You did in fact get it right. It is just your names that confused me. I would name them the other way around, because in the partition that is the first argument to mount is where the encrypted data goes. The second one is the mount point where data looks unencrypted. But I guess you are thinking about it from another perspective, namely which partitions are encrypted and which ones not. Sorry about the the confusion

----------

