linux-ext4 - [PATCH] fscrypt: correct collision claim for digested names

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20170501184332.37532-1-ebiggers3@gmail.com>
Date:   Mon,  1 May 2017 11:43:32 -0700
From:   Eric Biggers <ebiggers3@...il.com>
To:     linux-fscrypt@...r.kernel.org
Cc:     "Theodore Y . Ts'o" <tytso@....edu>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        linux-f2fs-devel@...ts.sourceforge.net, linux-ext4@...r.kernel.org,
        linux-mtd@...ts.infradead.org,
        Gwendal Grignou <gwendal@...omium.org>, hashimoto@...omium.org,
        kinaba@...omium.org, Eric Biggers <ebiggers@...gle.com>
Subject: [PATCH] fscrypt: correct collision claim for digested names

From: Eric Biggers <ebiggers@...gle.com>

As I noted on the mailing list, it's easier than I originally thought to
create intentional collisions in the digested names.  Unfortunately it's
not too easy to solve this, so for now just fix the comment to not lie.

Signed-off-by: Eric Biggers <ebiggers@...gle.com>
---
 include/linux/fscrypt_supp.h | 22 +++++++++-------------
 1 file changed, 9 insertions(+), 13 deletions(-)

diff --git a/include/linux/fscrypt_supp.h b/include/linux/fscrypt_supp.h
index e12c224a0d1e..cd4e82c17304 100644
--- a/include/linux/fscrypt_supp.h
+++ b/include/linux/fscrypt_supp.h
@@ -81,20 +81,16 @@ extern int fscrypt_fname_usr_to_disk(struct inode *, const struct qstr *,
  * followed by the second-to-last ciphertext block of the filename.  Due to the
  * use of the CBC-CTS encryption mode, the second-to-last ciphertext block
  * depends on the full plaintext.  (Note that ciphertext stealing causes the
- * last two blocks to appear "flipped".)  This makes collisions very unlikely:
- * just a 1 in 2^128 chance for two filenames to collide even if they share the
- * same filesystem-specific hashes.
+ * last two blocks to appear "flipped".)  This makes accidental collisions very
+ * unlikely: just a 1 in 2^128 chance for two filenames to collide even if they
+ * share the same filesystem-specific hashes.
  *
- * This scheme isn't strictly immune to intentional collisions because it's
- * basically like a CBC-MAC, which isn't secure on variable-length inputs.
- * However, generating a CBC-MAC collision requires the ability to choose
- * arbitrary ciphertext, which won't normally be possible with filename
- * encryption since it would require write access to the raw disk.
- *
- * Taking a real cryptographic hash like SHA-256 over the full ciphertext would
- * be better in theory but would be less efficient and more complicated to
- * implement, especially since the filesystem would need to calculate it for
- * each directory entry examined during a search.
+ * However, this scheme isn't immune to intentional collisions, which can be
+ * created by anyone able to create arbitrary plaintext filenames and view them
+ * without the key.  Making the "digest" be a real cryptographic hash like
+ * SHA-256 over the full ciphertext would prevent this, although it would be
+ * less efficient and harder to implement, especially since the filesystem would
+ * need to calculate it for each directory entry examined during a search.
  */
 struct fscrypt_digested_name {
 	u32 hash;
-- 
2.13.0.rc0.306.g87b477812d-goog