LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Michael Halcrow <mhalcrow@us.ibm.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
	Dustin Kirkland <dustin.kirkland@gmail.com>,
	Eric Sandeen <sandeen@redhat.com>,
	Tyler Hicks <tchicks@us.ibm.com>,
	David Kleikamp <shaggy@us.ibm.com>,
	Michael Halcrow <mhalcrow@us.ibm.com>
Subject: [PATCH 0/5] eCryptfs: Filename Encryption
Date: Tue, 4 Nov 2008 15:37:54 -0600	[thread overview]
Message-ID: <20081104213754.GC6675@halcrowt61p.austin.ibm.com> (raw)

This patchset implements filename encryption via a passphrase-derived
mount-wide Filename Encryption Key (FNEK) specified as a mount
parameter. Each encrypted filename has a fixed prefix indicating that
eCryptfs should try to decrypt the filename. When eCryptfs encounters
this prefix, it decodes the filename into a tag 70 packet and then
decrypts the packet contents using the FNEK, setting the filename to
the decrypted filename. Both unencrypted and encrypted filenames can
reside in the same lower filesystem.

Because filename encryption expands the length of the filename during
the encoding stage, eCryptfs will not properly handle filenames that
are already near the maximum filename length.

In the present implementation, eCryptfs must be able to produce a
match against the lower encrypted and encoded filename representation
when given a plaintext filename. Therefore, two files having the same
plaintext name will encrypt and encode into the same lower filename if
they are both encrypted using the same FNEK. This can be changed by
finding a way to replace the prepended bytes in the blocked-aligned
filename with random characters; they are hashes of the FNEK right
now, so that it is possible to deterministically map from a plaintext
filename to an encrypted and encoded filename in the lower
filesystem. An implementation using random characters will have to
decode and decrypt every single directory entry in any given directory
any time an event occurs wherein the VFS needs to determine whether a
particular file exists in the lower directory and the decrypted and
decoded filenames have not yet been extracted for that directory.

Thanks to Tyler Hicks and David Kleikamp for assistance in the
development of this patchset.

Signed-off-by: Michael Halcrow <mhalcrow@us.ibm.com>

             reply	other threads:[~2008-11-04 21:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-11-04 21:37 Michael Halcrow [this message]
2008-11-04 21:39 ` [PATCH 1/5] eCryptfs: Filename Encryption: Tag 70 packets Michael Halcrow
2008-11-06 22:12   ` Andrew Morton
2008-11-12 17:01     ` [PATCH] eCryptfs: Replace %Z with %z Michael Halcrow
2008-11-12 17:04     ` [PATCH] eCryptfs: Fix data types (int/size_t) Michael Halcrow
2008-11-12 17:06     ` [PATCH] eCryptfs: kerneldoc for ecryptfs_parse_tag_70_packet() Michael Halcrow
2008-11-04 21:39 ` [PATCH 2/5] eCryptfs: Filename Encryption: Header updates Michael Halcrow
2008-11-04 21:41 ` [PATCH 3/5] eCryptfs: Filename Encryption: Encoding and encryption functions Michael Halcrow
2008-11-05 18:17   ` Dave Hansen
2008-11-06 21:01     ` Michael Halcrow
2008-11-06 22:12   ` Andrew Morton
2008-11-12 17:11     ` [PATCH] eCryptfs: Clean up ecryptfs_decode_from_filename() Michael Halcrow
2008-11-04 21:42 ` [PATCH 4/5] eCryptfs: Filename Encryption: filldir, lookup, and readlink Michael Halcrow
2008-11-04 21:43 ` [PATCH 5/5] eCryptfs: Filename Encryption: mount option Michael Halcrow
2008-11-06 22:13   ` Andrew Morton
2008-11-14 16:47     ` Michael Halcrow
2008-11-05 15:57 ` [PATCH 0/5] eCryptfs: Filename Encryption Pavel Machek
2008-11-06 20:27   ` Michael Halcrow
2008-11-06 20:52     ` Dave Kleikamp
2008-11-06 22:11       ` Michael Halcrow

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=20081104213754.GC6675@halcrowt61p.austin.ibm.com \
    --to=mhalcrow@us.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dustin.kirkland@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sandeen@redhat.com \
    --cc=shaggy@us.ibm.com \
    --cc=tchicks@us.ibm.com \
    --subject='Re: [PATCH 0/5] eCryptfs: Filename Encryption' \
    /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

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).