linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Halcrow <lkml@halcrow.us>
To: Phillip Susi <psusi@cfl.rr.com>
Cc: Michael Halcrow <mhalcrow@us.ibm.com>,
	akpm@osdl.org, phillip@hellewell.homeip.net,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	viro@ftp.linux.org.uk, mcthomps@us.ibm.com, yoder1@us.ibm.com,
	toml@us.ibm.com, emilyr@us.ibm.com, daw@cs.berk
Subject: Re: eCryptfs Design Document
Date: Sat, 25 Mar 2006 13:50:15 -0600	[thread overview]
Message-ID: <20060325195015.GA8174@halcrow.us> (raw)
In-Reply-To: <442599D5.806@cfl.rr.com>

On Sat, Mar 25, 2006 at 02:28:21PM -0500, Phillip Susi wrote:
> Michael Halcrow wrote:
> >* A mount-wide passphrase is stored in the user session 
> >  keyring in the form of an authentication token.
> 
> You say several times that a mount-wide passphrase is used for the
> master key.  If that is the case, then it would be given at mount
> time and be bound to the super block.

The mount-wide passphrase in the user session keyring is actually not
necessary to keep around after the mount process is finished in this
release, and we will likely alter the design and implementation for
the 0.1 release to just remove it once the file key encryption key is
associated with the eCryptfs superblock object on mount.

In future releases, we will be storing multiple passphrase and public
key authentication tokens in the user's eCryptfs keyring, and so the
use of the kernel keyring will make a lot more sense. We are trying to
make things as simple as possible for the 0.1 release so as to limit
the complexity involved in analysis and debugging.

For the record, if you mount with one passphrase, create a file,
unmount, mount with another passphrase, and create another file, then
you will have two files side-by-side that are only accessible with
their respective passphrases. To access the first file, you need to
mount with the passphrase used to create that file in the first place,
and to access the second file, you need to mount with the passphrase
used to create that file. In future releases, the idea is that the
user will have two authentication tokens in the keyring, one for each
passphrase, so that he will be able to access either file under the
same mount.

> >passphrase into a key follows the S2K process as described in RFC
> >2440, in that the passphrase is concatenated with a salt; that data
> >block is then iteratively MD5-hashed 65,536 times to generate the key
> >that encrypts the file encryption key.
> 
> Are you saying that you salt the passphrase, hash that, then hash
> the hash, then hash that hash, and so on?  What good does repeatedly
> hashing the hash do?  Simply hashing the salted passphrase should be
> sufficient to obtain a key.

This approach is only used to help make dictionary attacks against the
passphrase a bit harder.

Mike

  reply	other threads:[~2006-03-25 19:55 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-24 22:25 eCryptfs Design Document Michael Halcrow
2006-03-24 23:12 ` James Morris
2006-03-27 16:17   ` Michael Thompson
2006-03-27 16:52   ` Michael Halcrow
2006-03-24 23:49 ` Andrew Morton
2006-03-25  0:13   ` Michael Halcrow
2006-03-25  0:33     ` Andrew Morton
2006-03-25  7:38       ` Miklos Szeredi
2006-03-27 23:31       ` Michael Halcrow
2006-03-28 16:00         ` Stephen C. Tweedie
2006-03-29 20:14           ` Michael Halcrow
2006-03-25 19:28 ` Phillip Susi
2006-03-25 19:50   ` Michael Halcrow [this message]
2006-03-26 17:10     ` Phillip Susi
2006-03-26 18:04       ` Michael Halcrow
2006-03-27  0:05         ` Phillip Hellewell
2006-03-27  2:53           ` Phillip Susi
2006-03-27 16:10             ` Michael Thompson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060325195015.GA8174@halcrow.us \
    --to=lkml@halcrow.us \
    --cc=akpm@osdl.org \
    --cc=daw@cs.berk \
    --cc=emilyr@us.ibm.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcthomps@us.ibm.com \
    --cc=mhalcrow@us.ibm.com \
    --cc=phillip@hellewell.homeip.net \
    --cc=psusi@cfl.rr.com \
    --cc=toml@us.ibm.com \
    --cc=viro@ftp.linux.org.uk \
    --cc=yoder1@us.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).