linux-kernel - Re: [PATCH] eCryptfs: Don't encrypt file key with filename key

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-prev] [day] [month] [year] [list]

Message-Id: <1236968511.4904.32.camel@t61p>
Date:	Fri, 13 Mar 2009 13:21:50 -0500
From:	Dustin Kirkland <kirkland@...onical.com>
To:	"Serge E. Hallyn" <serue@...ibm.com>
Cc:	Tyler Hicks <tyhicks@...ux.vnet.ibm.com>,
	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] eCryptfs: Don't encrypt file key with filename key

On Fri, 2009-03-13 at 08:39 -0500, Serge E. Hallyn wrote:
> Right, so the file name encryption key is the same for all the files,
> whereas you can have multiple file encryption key encryption keys.
> So this bug means that the ability to have multiple FEKEKs becomes
> completely worthless.

True, but only for files created up until this point with eCryptfs
filename encryption enabled.

Considering 2.6.29 is in RC, and Ubuntu Jaunty is still in Alpha (which
is carrying a backport of eCryptfs against 2.6.28), this should be a
relatively controlled set of affected individuals who should be at least
somewhat aware that they're running pre-release code.

+1, ACK on Tyler's patch.  It's a good, simple fix.  We're going to
carry that against Ubuntu's kernel.  I certainly hope that it will make
it into 2.6.29 which should land on a lot more systems.

> This makes me wonder if it's not worth doing a complete code-vs-design
> comparison to make sure there are no other such gems hidden away.

Definitely a good idea.

> Tyler, do you have a user-space (hopefully easier-to-read) parser for
> encrypted ecryptfs files?  (ISTR they were closely following a gpg
> format)

I'll take the to-do to fix this in userspace.  I've file a bug for my
own tracking purposes.  I'll update this as I enhance the ecryptfs-stat
utility:
 * https://bugs.launchpad.net/ecryptfs/+bug/342398

-- 
:-Dustin

Dustin Kirkland
Ubuntu Server Developer
Canonical, LTD
kirkland@...onical.com
GPG: 1024D/83A61194

--
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/