linux-kernel - [PATCH 0/5] eCryptfs: Filename Encryption

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 4 Nov 2008 15:37:54 -0600
From:	Michael Halcrow <mhalcrow@...ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Dustin Kirkland <dustin.kirkland@...il.com>,
	Eric Sandeen <sandeen@...hat.com>,
	Tyler Hicks <tchicks@...ibm.com>,
	David Kleikamp <shaggy@...ibm.com>,
	Michael Halcrow <mhalcrow@...ibm.com>
Subject: [PATCH 0/5] eCryptfs: Filename Encryption

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