pam_ecryptfs.so causes authentication to be slow by unnecessary subsequent unwraps of wrapped-passphrase

This also happens to me. Similar logs to the ones shown above. Similar 5 second pause.

My PC was upgraded to hardy and I used the following URL to setup the Private directory: https://wiki.ubuntu.com/EncryptedPrivateDirectory

Could you guys post your:
 * /etc/pam.d/common-auth
 * /etc/pam.d/common-login
 * /etc/pam.d/common-session
files?

There might be something else odd going on in there ...

:-Dustin

Attached. I didn't have common-login, but I did have login, which I've included instead.

I see this on two computers, one is a fresh Intrepid install, one an upgrade.

Sorry, I mean common-password, not login.

The only difference between your config and mine is:

:-Dustin

On Mon, Nov 24, 2008 at 7:15 PM, Dustin Kirkland
<email address hidden> wrote:
> The only difference between your config and mine is:

Sorry to leave you hanging ... I have samba line in mine.

--
:-Dustin

'k, attaching common-password.

How much CPU/Memory do you have on the slow systems?

In a rather minimal virtual machine (fraction of a processor, 256MB memory), the login process can take up to 2 seconds. I'd say maybe 2 seconds might be expected. 4 or 5 seconds seems rather long on normal hardware...

A few nitty gritty details on what's going on with eCryptfs... It has to perform several rather CPU/Memory intensive operations upon login, such as decrypting your wrapped-passphrase file, calculating the fekek (file encryption key encryption key) which involves hashing a value some 65,000 times, and calculating the signatures. These procedures are rather cpu-intensive, I'm afraid. On a very slow CPU, I suppose this might take a couple of seconds?

:-Dustin

By the way, I have silenced a number of those non-valuable warnings in
one of the recent uploads for Jaunty.

:-Dustin

On Mon, 2009-01-26 at 05:27 +0000, Dustin Kirkland wrote:
> How much CPU/Memory do you have on the slow systems?

I'm using a Dell Mini 12, which is a dual-core
Intel(R) Atom(TM) CPU Z530 @ 1.60GHz (which often
throttles down to 800MHz), with 1 GB RAM. I
was seeing something that was taking a very long time,
which seemed a lot more like timing out attempting to
access a resource rather than any difficulty crunching
data.

I notice it mostly on my eee 701, where it will timeout when I get it wrong faster than it will go through when I get it right. This is something like 800Mhz with 2Gb RAM. However, my dev laptop is dual core, 1.66Ghz per core, and it's a noticeable (although less) delay there also.

I don't know anything about PAM modules, but I wonder if it could skip that process when it's not needed (i.e. if it's already unlocked) or do it in a separate thread given it's not needed for authentication as such.

Hi, same "problem" here, eee 701 with ecryptfs:
slow login (~5sec) and same delay on every other operation that involve authentication... as sudo.
As described by Dustin, i think problem is cpu related; to test try the following:

open 2 terminal (shell)
in the first type "top -d1" to show cpu usage
in the second type "sudo ls" (or any other command to "authenticate" with sudo), enter the password and then immediatly switch to the other shell (the one with top -d1 running)
you will see that the process sudo is at the top with nearly 100% of cpu usage.

So seems problem is not a bug, but is related to the working mode of ecryptfs (decrypting wrapped-passphrase file, calculating the fekek and calculating the signatures)

bye

Hi all,

Thanks for the bug report.

Okay I've tracked this down. It helped quite a bit to see that it's mostly Atom processors (eee pc's, and netbooks).

This is totally a function of eCryptfs' key strengthening mechanism. For more information about key strengthening, see:
 * http://en.wikipedia.org/wiki/Key_strengthening

The goal here is to make your eCryptfs keys as strong as possible. In the course of generating your fekek (file encryption key encryption key -- see the ecryptfs source code for more details), we perform a has iterative sha512 hash ~65,000 times. This is a non-trivial operation, and it's intended to make brute force attacks against your passphrases 65,000 times harder.

While many desktop/laptop/server CPU's can do this key strengthening in about ~1 second, it's taking a bit longer on lower power processors.

Unfortunately, this is not something we're going to be able to solve without breaking the ABI/API of eCryptfs. We would need two different versions--a weak-key and a normal key mode. I doubt we're going to solve this any time soon. I'm going to have to mark this "won't fix" for now. Sorry!

:-Dustin

Dustin: Have you considered moving unwrap to PAM session phase, instead of auth? It makes no sense to me to block the whole authentication to mount your encrypted folder. The auth phase should be reserved to authentication checking - session is here for you, where you can do this while starting other apps.

I'm using this right now, that solves the issue. Gaining about 2 seconds in not negligible in a system where we're struggling to save milliseconds in the boot process. ;-)

OK, my proposal was missing something - you need the password to unwrap... :-p

So the best would IMHO that you simply check that the password is the right one during the auth phase, and only unwrap the folder after, for example in a child process. For now, in the pam_sm_authenticate function, there's at the end:
> 178 tmp_pid = waitpid(child_pid, NULL, 0);

The only interest of waiting for the child to finish is to return PAM_SUCCESS on success, which is not really useful since ecryptfs is always optional. So I suggest the module forks ASAP and only returns error if the password is not the right one.

Please do something, that's really lousy that you need 2 seconds to unlock gnome-screensaver! ;-)

This would be nice. It still annoys me that it takes longer for sudo to work when I get the password right than when I get it wrong, even though the encrypted directory is already unlocked (and so it seems to me that all of that time is completely wasted: the key is never going to be used)

Please fix it!
Sometimes, after standby my machine needs more than 10 sec. to unlock the gnome-screensaver. This is ridiculous.
As said before, the key is already there the ecryptfs is already mounted. No need to unwrap the passphrase at unlock-time.
Thank you!

Earlier this week, I uploaded ecryptfs-utils-78 to karmic, which
should address the issue you mention.

The fix first detects if your encrypted home or private directory is
already mounted, and if so, it bypasses the most performance intensive
work.

This means that all subsequent authentications that go through
pam_ecryptfs should be significantly faster. This includes sudo, ssh,
gnome, kde, xfce, screensavers, etc. The first login is not affected,
and it will have to do the initial key loading and decryption, etc,
but subsequent logins are much, much faster.

Nice!

Don't you think it would be worth keeping this bug open so that we can eventually get rid of _any_delay by starting unwrapping in a parallel process instead of blocking PAM? See my comment 14.

The initial bug filed, as described is fixed. Once your key is loaded into the keyring, pam_ecryptfs won't try to unnecessarily unwrap your key again.

Please file a new bug on a different issue.

Dustin

I believe I may be seeing this same (or similar) bug on Ubuntu Ubuntu 16.04.1

Password verification is extremely slow (for sudo, or unlocking gnome-screensaver), on the order of a minute or more. For example:

$ date
Wed Jan 18 11:19:20 CET 2017
$ sudo date
[sudo] password for bjmc:
Wed Jan 18 11:20:07 CET 2017

I see this entry in /var/log/syslog:

sudo: pam_ecryptfs: pam_sm_authenticate: /home/bjmc is already mounted

Should I open a separate bug report? Is there anything I need to check first, or include in the bug report?

Same here, I am experiencing this issue for the first time. Login, Sudo, and unlocking all take a very very long time. Very annoying. Kubuntu 16.04. Please let me know if I can provide any more helpful info.