From: Michael Halcrow <mhalcrow@us.ibm.com>
To: James Morris <jmorris@namei.org>
Cc: Andrew Morton <akpm@osdl.org>,
phillip@hellewell.homeip.net, linux-kernel@vger.kernel.org,
linux-fsdevel@vger.kernel.org, viro@ftp.linux.org.uk,
mike@halcrow.us, mcthomps@us.ibm.com, yoder1@us.ibm.com,
toml@us.ibm.com, emilyr@us.ibm.com, daw@cs.berkeley.edu
Subject: Re: eCryptfs Design Document
Date: Mon, 27 Mar 2006 10:52:08 -0600 [thread overview]
Message-ID: <20060327165208.GA14817@us.ibm.com> (raw)
In-Reply-To: <Pine.LNX.4.64.0603241757090.27964@excalibur.intercode>
On Fri, Mar 24, 2006 at 06:12:46PM -0500, James Morris wrote:
> What about other attacks on MD5?
The only attacks that I am aware of against MD5 require known prefix
values, and all of the prefix values in eCryptfs are secret.
> Hard coding it into the system makes me nervous, what about making
> this selectable?
This is yet another attribute that we would like to include in policy
support in future versions of eCryptfs. There are many things we could
have made parameterizable in release 0.1, but we decided to just lock
it down to a single hash algorithm, cipher/key size, chaining mode,
and so forth. Once eCryptfs has been weathered in its current state,
we would like to incrementally start allowing more flexibility in
these cryptographic attributes on a step-by-step basis.
Those who reviewed the design document did express concern over the
fact that we are using MD5, simply because of the known-prefix
attacks, but up to now, based on what is known about the cryptographic
properties of the hash algorithms, nobody has presented a reason why
using something like SHA-256 or RIPEMD-160 for either the S2K
operation or the root IV generation would make eCryptfs any more
secure than it currently is.
> > By default, eCryptfs selects AES-128. Later versions of eCryptfs
> > will allow the user to select the cipher and key length.
>
> Also, what about making the encryption mode selectable, to at least
> allow for like LRW support in addition to CBC?
That also is another feature that we would like to defer for a future
release. Changing the chaining mode may have security implications,
and so we would prefer to think through how that feature can be
intelligently offered to the user. For instance, we would not want a
user to just be able to blindly select ECB mode, which he might
naively do if he finds that it helps performance.
Thanks,
Mike
next prev parent reply other threads:[~2006-03-27 16:52 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 [this message]
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
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=20060327165208.GA14817@us.ibm.com \
--to=mhalcrow@us.ibm.com \
--cc=akpm@osdl.org \
--cc=daw@cs.berkeley.edu \
--cc=emilyr@us.ibm.com \
--cc=jmorris@namei.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcthomps@us.ibm.com \
--cc=mike@halcrow.us \
--cc=phillip@hellewell.homeip.net \
--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).