From: Phillip Lougher <phillip@lougher.demon.co.uk>
To: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
Cc: Kallol Biswas <kbiswas@neoscale.com>,
linux-kernel@vger.kernel.org,
"linux-fsdevel@vger.kernel.org" <linux-fsdevel@vger.kernel.org>
Subject: Re: partially encrypted filesystem
Date: Thu, 04 Dec 2003 18:20:05 +0000 [thread overview]
Message-ID: <3FCF7AD5.4050501@lougher.demon.co.uk> (raw)
In-Reply-To: <20031204172653.GA12516@wohnheim.fh-wedel.de>
Jörn Engel wrote:
>
> So - as sick as it sounds - jffs2 may actually be the fs of choice
> when doing encryption, even though working on a hard drive and not
> flash. Cool. :)
>
Considering that Jffs2 is the only writeable compressed filesystem, yes.
What should be borne in mind is compressed filesystems never expect
the data after compression to be bigger than the original data. In the
case where the compressed data is bigger, the original data is used
instead, which is hardy ideal for an encrypted filesystem, and so more
than a direct substitution of compression function for encrypt function
is needed - this is of course only relevant if the encryption algorithm
used could return more data...
>
> Depends on how much security you really care about. If you really
> don't mind the pain involved, some metadata should explicitly *not* be
> encrypted, to avoid known plaintext attacks. To a serious attacker,
> this could be a death stroke for ext[23] over cryptoloop, actually.
>
You're assuming the metadata (inodes, indexes and directory entries),
are encrypted with the same key, and therefore decrypting the directory
data using plaintext attacks will give the attacker the key to the
entire metadata? There is nothing preventing the directory data being
encrypted separately with a different key, and therefore a plaintext
attack would get nothing more than the directory information.
As you say, you highlight a drawback with cryptoloop and cloop, because
they cannot distinquish between different types of data. This sort of
thing should always be done at the fs level rather than the block level...
> In real life, though, the humans are usually the weakest link, so this
> doesn't matter anyway.
>
Hmmm, why not give give up completely then?
Phillip
next prev parent reply other threads:[~2003-12-04 18:23 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-03 21:07 partially encrypted filesystem Kallol Biswas
2003-12-03 21:44 ` Richard B. Johnson
2003-12-03 23:20 ` bill davidsen
2003-12-03 21:44 ` Jörn Engel
2003-12-04 0:08 ` Linus Torvalds
2003-12-04 1:25 ` Jeff Garzik
2003-12-04 2:08 ` Linus Torvalds
2003-12-04 3:59 ` H. Peter Anvin
2003-12-04 2:37 ` Charles Manning
2003-12-04 14:17 ` Jörn Engel
2003-12-04 15:20 ` Linus Torvalds
2003-12-04 16:07 ` Phillip Lougher
2003-12-04 17:26 ` Jörn Engel
2003-12-04 18:20 ` Phillip Lougher [this message]
2003-12-04 18:40 ` Jörn Engel
2003-12-04 19:41 ` Erez Zadok
2003-12-05 11:20 ` Jörn Engel
2003-12-05 16:16 ` Erez Zadok
2003-12-05 19:14 ` Matthew Wilcox
2003-12-05 19:47 ` Erez Zadok
2003-12-05 20:28 ` Matthew Wilcox
2003-12-05 21:38 ` Pat LaVarre
2003-12-06 0:15 ` Maciej Zenczykowski
2003-12-06 1:35 ` Pat LaVarre
2003-12-06 2:39 ` Valdis.Kletnieks
2003-12-06 11:43 ` Maciej Zenczykowski
2003-12-07 0:04 ` Shaya Potter
2003-12-08 14:08 ` Jörn Engel
2003-12-06 0:50 ` Phillip Lougher
2003-12-08 11:37 ` David Woodhouse
2003-12-08 13:44 ` phillip
2003-12-08 14:07 ` David Woodhouse
2003-12-10 1:16 ` [OT?]Re: " Charles Manning
2003-12-10 17:45 ` Phillip Lougher
2003-12-09 23:40 ` Pat LaVarre
2003-12-10 0:07 ` Pavel Machek
2003-12-10 1:28 ` Pat LaVarre
2003-12-10 2:13 ` Charles Manning
2003-12-05 19:58 ` Pat LaVarre
2003-12-08 11:28 ` David Woodhouse
2003-12-08 13:49 ` phillip
2003-12-04 19:18 ` David Wagner
2003-12-05 13:02 ` Jörn Engel
2003-12-05 17:28 ` Frank v Waveren
2003-12-05 23:59 ` David Wagner
2003-12-19 15:01 ` Rik van Riel
2003-12-04 3:10 ` Valdis.Kletnieks
2003-12-04 18:16 ` Hans Reiser
2003-12-06 19:56 Pat LaVarre
2003-12-06 22:07 ` Maciej Zenczykowski
2003-12-10 3:22 Valient Gough
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=3FCF7AD5.4050501@lougher.demon.co.uk \
--to=phillip@lougher.demon.co.uk \
--cc=joern@wohnheim.fh-wedel.de \
--cc=kbiswas@neoscale.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/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;
as well as URLs for NNTP newsgroup(s).