linux-ext4 - Re: [PATCH] fscrypt: use 32 bytes of encrypted filename

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]

Date:   Mon, 24 Apr 2017 23:19:00 +0200
From:   Richard Weinberger <richard.weinberger@...il.com>
To:     Richard Weinberger <richard@....at>
Cc:     Eric Biggers <ebiggers3@...il.com>,
        Gwendal Grignou <gwendal@...omium.org>,
        Ryo Hashimoto <hashimoto@...omium.org>,
        Eric Biggers <ebiggers@...gle.com>,
        linux-f2fs-devel@...ts.sourceforge.net,
        linux-fscrypt@...r.kernel.org,
        "linux-mtd@...ts.infradead.org" <linux-mtd@...ts.infradead.org>,
        "Theodore Ts'o" <tytso@....edu>, linux-ext4@...r.kernel.org,
        Kazuhiro Inaba <kinaba@...omium.org>,
        David Gstir <david@...ma-star.at>
Subject: Re: [PATCH] fscrypt: use 32 bytes of encrypted filename

Eric,

On Wed, Apr 19, 2017 at 7:21 PM, Richard Weinberger <richard@....at> wrote:
>> 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.)
>
> Let me dig into this, maybe I made a boo boo.
> The idea was looking up by the filename hash and resolving
> possible collisions using the secondary hash.

In ubifs_lookup() we handle two cases:
1. lookup of a bigname, both fscrypt_name->hash and ->minor_hash are valid.
    ->hash is r5(diskname) and ->minor_hash is the secondary hash, AKA cookie.
   UBIFS fed this hashes in ubifs_readdir() to fscrypt.
2. lookup of a non-bigname, in this case we compute r5(diskname) and
use the diskname
    itself for lookups.

So, in case 1 we avoid collisions by using a 64bit key and in case 2 by using
the 32bit key plus a linear search and memcmp() of diskname.

-- 
Thanks,
//richard