All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Weinberger <richard@nod.at>
To: Eric Biggers <ebiggers3@gmail.com>
Cc: Gwendal Grignou <gwendal@chromium.org>,
	Theodore Ts'o <tytso@mit.edu>, Eric Biggers <ebiggers@google.com>,
	linux-ext4@vger.kernel.org, linux-fscrypt@vger.kernel.org,
	kinaba@chromium.org, hashimoto@chromium.org,
	David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Subject: Re: [PATCH] fscrypt: use 32 bytes of encrypted filename
Date: Wed, 19 Apr 2017 19:12:01 +0200	[thread overview]
Message-ID: <bdda413c-1452-9e55-53ff-34eb17ef4c3b@nod.at> (raw)
In-Reply-To: <20170419170940.GA89688@gmail.com>

Eric,

Am 19.04.2017 um 19:09 schrieb Eric Biggers:
> Hi Richard,
> 
> On Wed, Apr 19, 2017 at 03:37:42PM +0200, Richard Weinberger wrote:
>>>
>>> Tested only on ext4.
>>
>> I hope you classify this patch as RFC then.
>> We'll have problems when you just develop and test for ext4. :-)
>>
> 
> It's a little difficult for people to test stuff on UBIFS without a turn-key
> solution like kvm-xfstests where they can just run something like
> 'kvm-xfstests -c ext4,f2fs,ubifs -g encrypt'.
> 
> I did post patches to add UBIFS support to xfstests and kvm-xfstests a few
> months ago; maybe you're interested in taking them over and working to get them
> merged?

I assigned this talk already to David.
He can tell what the status is.

>>> diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
>>> index c4a389a6027b..14b2a2335a32 100644
>>> --- a/fs/ext4/namei.c
>>> +++ b/fs/ext4/namei.c
>>> @@ -1257,8 +1257,8 @@ static inline int ext4_match(struct ext4_filename *fname,
>>>                         int ret;
>>>                         if (de->name_len < 16)
>>>                                 return 0;
>>> -                       ret = memcmp(de->name + de->name_len - 16,
>>> -                                    fname->crypto_buf.name + 8, 16);
>>> +                       ret = memcmp(de->name + de->name_len - 32,
>>> +                                    fname->crypto_buf.name + 8, 32);
>>>                         return (ret == 0) ? 1 : 0;
>>>                 }
>>>                 name = fname->crypto_buf.name;
>>
>> Can the code still be able to read filenames which have been encrypted
>> using the "old" scheme?
>>
> 
> The patch only changes the presentation of long encrypted filenames when
> accessed without the key.  It doesn't change how filenames are encrypted.

Thanks for pointing this out.

Thanks,
//richard

  reply	other threads:[~2017-04-19 17:12 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-18 21:06 [PATCH] fscrypt: use 32 bytes of encrypted filename Gwendal Grignou
2017-04-18 23:01 ` 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-19 20:44           ` Jaegeuk Kim
2017-04-21  7:44           ` Eric Biggers
2017-04-21  7:44             ` Eric Biggers
2017-04-21 17:21             ` [f2fs-dev] " Gwendal Grignou
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 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
2017-04-19 17:21       ` Richard Weinberger
2017-04-24 21:19         ` Richard Weinberger
2017-04-18 23:37 ` Andreas Dilger
2017-04-19 13:37 ` Richard Weinberger
2017-04-19 13:41   ` Richard Weinberger
2017-04-19 17:09   ` Eric Biggers
2017-04-19 17:12     ` Richard Weinberger [this message]
2017-04-20 11:24       ` David Oberhollenzer

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=bdda413c-1452-9e55-53ff-34eb17ef4c3b@nod.at \
    --to=richard@nod.at \
    --cc=david.oberhollenzer@sigma-star.at \
    --cc=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-fscrypt@vger.kernel.org \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.