From: Michael Halcrow <lkml@halcrow.us>
To: V Bhanu Chandra <vbhanu.lkml@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFC] Encrypting file system
Date: Mon, 6 Mar 2006 11:37:00 -0600 [thread overview]
Message-ID: <20060306173659.GA12970@halcrow.us> (raw)
In-Reply-To: <Pine.LNX.4.64.0603061600540.16555@vattikonda.junta.iitk.ac.in>
On Mon, Mar 06, 2006 at 04:01:33PM +0530, V Bhanu Chandra wrote:
> I am thinking of designing and implementing a new native encrypting
> file system for the linux kernel as a part of a student / research
> project. Unlike dm-crypt/loop-AES/cryptoloop, I plan to target
> slightly more ambitious user specifications such as: per-file random
> secret encryption keys which are in-turn encrypted using the public
> keys of all users having access to that filesystem object (a copy
> each), and these "tokens" stored along with the file as meta-data
> (in an extended attribute, for example).
You have just described exactly what I presented at OLS 2004 and
2005. The paper is available in the symposium proceedings. Another
post on this thread pointed to the eCryptfs web site:
http://ecryptfs.sourceforge.net/
A version (0.1) with mount-wide passphrase support (with a random
session key per file) has been fully implemented and is available for
immediate use. If you are running kernel version 2.6.15, you can build
eCryptfs as a stand-alone module. There is a preliminary design
document under development that is available from the web site too. It
covers passphrase-only functionality for version 0.1, and I am in the
process of working on a design document for version 0.2, which will
include per-file public key support. In version 0.3, I plan to
implement more advanced key management and policy support.
> It would be helpful if someone has implemented (or is working on) a
> patch for the kernel that implements RSA in the CryptoAPI, else I
> might have to resort to have a user-space service for key management
> tasks.
For eCryptfs, I have decided that the public key operations be best
routed to userspace code due to their high computational overhead and
the need for additional operations that are necessary to make public
key meaningful from a security perspective, such as certificate
processing, CRL's, and so forth.
Thanks,
Mike Halcrow
eCryptfs Lead Developer
next prev parent reply other threads:[~2006-03-06 17:41 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-06 10:31 [RFC] Encrypting file system V Bhanu Chandra
2006-03-06 12:17 ` Mario 'BitKoenig' Holbe
2006-03-06 13:05 ` Eduard Bloch
2006-03-06 17:37 ` Michael Halcrow [this message]
2006-03-06 21:36 ` AMD64 X2 lost ticks on PM timer Timo Schroeter
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=20060306173659.GA12970@halcrow.us \
--to=lkml@halcrow.us \
--cc=linux-kernel@vger.kernel.org \
--cc=vbhanu.lkml@gmail.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