Re: Key derivation and passprhase wrapping

[Tyler Hicks <tyhicks@canonical.com>]

[-- Attachment #1: Type: text/plain, Size: 2378 bytes --]

On 2016-01-18 11:27:37, Wiebe Cazemier wrote:
> Hi, 
> 
> I was looking at the ecryptfs source code, and saw that the actual
> encryption key inserted into the kernel keyring is the *original*
> wrapped passphrase, SHA512'ed 65536 times. Why is a user-given
> passphrase encrypted as key, and not data from /dev/random?

This assumes that the mount.ecryptfs helper is used and not the
mount.ecryptfs_private helper.

mount.ecryptfs does key stretching (SHA512 * 65536) on a user-provided
passphrase and uses that as the file encryption key encryption key
(FEKEK). This keeps things simple so that the only thing a user needs to
access their encrypted files is the passphrase. There's no chance of
losing track of a file containing a wrapped FEKEK that is randomly
generated. However, mount.ecryptfs could be extended to make use of
wrapped, randomly generated FEKEK which would provide a more secure
option.

> I unwrapped the passphrase on my Linux Mint system and saw it is
> actually a random string, so the Ubuntu/Mint installer took care of it
> for me. But why is that responsibility given to the user / outside
> world?

All of the logic that set up that random FEKEK is in upstream
ecryptfs-utils. The confusion is probably caused by the unfortunate
split between the mount.ecryptfs and mount.ecryptfs_private helpers.

> One of the problems is that I can't change it. Had I made a
> ecryptfs archive myself and wrapped 'hello' as passphrase, that weak
> key will be used and cannot be changed by rewrapping.
> 
> Would it be possible/feasible to do something like:
> 
> * generate random encryption key A for insertion into kernel keyring.
> * derive encryption key B from password with 'generate_passphrase_sig(...)' to encrypt key A.
> * In v2 wrapped passphrase file, Octets 26-N1, store encrypted A, instead of encrypted passphrase.

I'm not following the intent here. You're wanting to change the FEKEK
that the Ubuntu/Mint installer generated?

Tyler

> 
> Depending on how it's implemented, it could even be done completely backwards compatible (by ignoring the to-wrap passphrase).
> 
> Regards,
> 
> Wiebe
> --
> To unsubscribe from this list: send the line "unsubscribe ecryptfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]