Re: eCryptfs Design Document

[Michael Halcrow <mhalcrow@us.ibm.com>]

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/