ecryptfs-devel team mailing list archive

[Tyler Hicks <tyhicks@xxxxxxxxxxxxxxxxxx>]

On 10/05/2009 12:16 PM, Dave Hansen wrote:
> On Mon, 2009-10-05 at 11:19 -0500, Dustin Kirkland wrote:
>> It's for this reason that we've chosen not to use a salt in the
>> default Ubuntu encrypted home directory setup.  The mount passphrase
>> is already randomly generated, which thwarts dictionary attacks.  We
>> decided that the extra bits of security offered by a salt were not
>> worth the inevitable inadvertent loss of salt by legitimate users of
>> ecryptfs.
> 
> How big was that salt?  

8 bytes

> I'm just thinking of the UNIX password salts
> that were only 12 bits or so.  They were intended to be brute-forced
> through at each login.  If it is small, perhaps it is worth just
> scripting it to try and recover.

The salt is stored in the header area of the encrypted file.  The
following command should* dump most eCryptfs files salt.  Keep in mind
that this is the lower, encrypted file being used here:

$ hexdump -C -s 32 -n 8 lower/foo
00000020  00 11 22 33 44 55 66 77                           |.."3DUfw|
00000028

The default is 0011223344556677.  Compare the salt from an old file to
the salt from a new file and see if they are different.

While you're at it, check to see if the key signatures used to encrypt
the "old" and "new" eCryptfs files are the same.  This should* do it:

$ hexdump -C -s 73 -n 8 lower/foo
00000049  25 3c a7 e8 88 11 d1 84                           |%<......|
00000051

You'll have a different key signature, but you should see the same key
signature in your old and new eCryptfs files.  It should also be the
same key signature that you see in your kernel keyring:

$ keyctl show
Session Keyring
       -3 --alswrv    500   500  keyring: _ses
466662124 --alswrv    500    -1   \_ keyring: _uid.500
416823230 --alswrv    500   500       \_ user: 253ca7e88811d184

This reminds me how badly we need header parsing functionality in
libecryptfs...

* Note: The problem with these hexdump commands is that there's some
wiggle room in a few of the fields in the header section so the offsets
could be off, but I expect it will work for you.  If you feel
comfortable *privately* sending me the header section of an old and new
file, then I can manually parse it.  Here's how to dump it:

$ hexdump -C -n 8192 lower/foo

Tyler

Attachment: signature.asc
Description: OpenPGP digital signature