LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* [PATCH 0/5] eCryptfs: Filename Encryption
@ 2008-11-04 21:37 Michael Halcrow
  2008-11-04 21:39 ` [PATCH 1/5] eCryptfs: Filename Encryption: Tag 70 packets Michael Halcrow
                   ` (5 more replies)
  0 siblings, 6 replies; 20+ messages in thread
From: Michael Halcrow @ 2008-11-04 21:37 UTC (permalink / raw)
  To: Andrew Morton
  Cc: LKML, Dustin Kirkland, Eric Sandeen, Tyler Hicks, David Kleikamp,
	Michael Halcrow

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>

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2008-11-14 16:47 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-11-04 21:37 [PATCH 0/5] eCryptfs: Filename Encryption Michael Halcrow
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

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