From: Eric Biggers <ebiggers3@gmail.com>
To: Richard Weinberger <richard.weinberger@gmail.com>
Cc: Gwendal Grignou <gwendal@chromium.org>,
hashimoto@chromium.org, Eric Biggers <ebiggers@google.com>,
linux-f2fs-devel@lists.sourceforge.net,
linux-fscrypt@vger.kernel.org,
"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
Theodore Ts'o <tytso@mit.edu>,
linux-ext4@vger.kernel.org, kinaba@chromium.org
Subject: Re: [PATCH] fscrypt: use 32 bytes of encrypted filename
Date: Wed, 19 Apr 2017 10:16:33 -0700 [thread overview]
Message-ID: <20170419171633.GB89688@gmail.com> (raw)
In-Reply-To: <CAFLxGvwtFQW=NL3NrNHx-vWR3wSUtewnBRy1XzMqRNTV8f5vwQ@mail.gmail.com>
On Wed, Apr 19, 2017 at 03:40:13PM +0200, Richard Weinberger wrote:
> > Strangely, f2fs and ubifs do not use the bytes from the filename at all when
> > trying to find a specific directory entry in this case. So this patch doesn't
> > really affect them. This seems unreliable; perhaps we should introduce a
> > function like "fscrypt_name_matches()" which all the filesystems could call?
> > Can any of the f2fs and ubifs developers explain why they don't look at any
> > bytes from the filename?
>
> Not sure if I understand you correctly, but for long filenames UBIFS
> does a lookup
> by hash/cookie, not by filename.
>
Well, like I said to Jaegeuk for F2FS, that's what the code does, but _why_?
Like F2FS, it's probably not the case that the hash is sufficient to reliably
identify a directory entry. Granted, UBIFS does it a lot better than F2FS since
UBIFS uses two 32-bit hashes rather than just one, but it seems the second hash
may be neither necessary nor sufficient to identify a specific directory entry,
and it should be looking at the bytes of ciphertext from the filename instead,
like what ext4 does. (Provided that is fixed to account for how CTS mode
encryption works.)
- Eric
next prev parent reply other threads:[~2017-04-19 17:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20170418210642.6039-1-gwendal@chromium.org>
2017-04-18 23:01 ` [PATCH] fscrypt: use 32 bytes of encrypted filename Eric Biggers
2017-04-19 0:10 ` Eric Biggers
2017-04-19 1:42 ` [f2fs-dev] " Jaegeuk Kim
2017-04-19 4:01 ` Eric Biggers
2017-04-19 20:44 ` Jaegeuk Kim
2017-04-21 7:44 ` Eric Biggers
2017-04-21 17:21 ` Gwendal Grignou
2017-04-21 18:53 ` [f2fs-dev] " Eric Biggers
2017-04-21 17:35 ` Jaegeuk Kim
2017-04-21 19:26 ` [f2fs-dev] " Eric Biggers
2017-04-19 20:31 ` Gwendal Grignou
2017-04-19 13:40 ` Richard Weinberger
2017-04-19 17:16 ` Eric Biggers [this message]
2017-04-19 17:21 ` Richard Weinberger
2017-04-24 21:19 ` Richard Weinberger
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=20170419171633.GB89688@gmail.com \
--to=ebiggers3@gmail.com \
--cc=ebiggers@google.com \
--cc=gwendal@chromium.org \
--cc=hashimoto@chromium.org \
--cc=kinaba@chromium.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-f2fs-devel@lists.sourceforge.net \
--cc=linux-fscrypt@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=richard.weinberger@gmail.com \
--cc=tytso@mit.edu \
/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).