From patchwork Mon May 1 18:43:32 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Eric Biggers X-Patchwork-Id: 9706825 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id F1B0660387 for ; Mon, 1 May 2017 18:45:25 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id E55AA27F95 for ; Mon, 1 May 2017 18:45:25 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id D6AC4280FC; Mon, 1 May 2017 18:45:25 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.3 required=2.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, RCVD_IN_SORBS_SPAM, T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0338C27F95 for ; Mon, 1 May 2017 18:45:24 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751370AbdEASpX (ORCPT ); Mon, 1 May 2017 14:45:23 -0400 Received: from mail-pg0-f67.google.com ([74.125.83.67]:35205 "EHLO mail-pg0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750794AbdEASpV (ORCPT ); Mon, 1 May 2017 14:45:21 -0400 Received: by mail-pg0-f67.google.com with SMTP id c2so6800552pga.2; Mon, 01 May 2017 11:45:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id; bh=F85NeXzuZbmj5cDE/GG5m6zxg7SjDhvP/LLJIJcjHXc=; b=RvYL50MMJ2k8Oz8IaJiXbVtU4WUvpuUjF/H/FlN6Yh74alh6jJFmhDF71OCRe3RjJB ERjUiS2xVt9h8HMv/RgdGxX5X/r+XeH958k7uRLWYWcVUHZOc0FTjAAzI+VXhdFIDGRD YXolkrTunUU3vqcgdA/iXBp+QM+QxH6uAnCZKitikqTJakAOaWO5WumTdFdTqFhyhp+l S+gtlQW0n08dvwdsCyqevzegYejBMpa7vCXPoqulLSlMr3uBjuPJjcglgDK6vqG+VEvE ApELrUsV6UgJS6I3FJbCP4SKSAwDUdJFjv4Z7z3iDbnNqB1EL08YhFfCqAAv3gGewQMw QHqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=F85NeXzuZbmj5cDE/GG5m6zxg7SjDhvP/LLJIJcjHXc=; b=VJnkIgvy+Jy7Dku9uqqbH/8Yg03Rtb+LFQl1W/pirwFGch+0/O12I+buxs24RuQXDU kg13sR8YMcmzzC/Ja9mbZkWKDtpFOAjkMbSwmMf3zZ9evSUQ0wHI0iOQcCuAPgKgtews 7JXnWPABgl98YPVeftIuAGPGWJ9dUbFIBiYLtofjUUqYbV5DAfpCd1wBKtGHN4u3CJdK up76+WXSH8BV0qPA2ekxyJM19IDZXerTOF5lmw4NeJGQpW7BUUT7bV3lCJsxkjpAM4DR royL0VRwZOAOwjuuUsncduTxav+esljouWdIXEt3fJBks8/afCJ+zkSO+K5wqMlQsSYu qpZA== X-Gm-Message-State: AN3rC/4dD00Z8BMxEMuh+n5jFf+WWa5lX9GMOxo66qpQXGqm4++03ie9 swhRbsfHPHmDOw== X-Received: by 10.98.70.84 with SMTP id t81mr10229161pfa.245.1493664321002; Mon, 01 May 2017 11:45:21 -0700 (PDT) Received: from ebiggers-linuxstation.kir.corp.google.com ([100.119.30.131]) by smtp.gmail.com with ESMTPSA id p62sm24966634pfi.7.2017.05.01.11.45.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 May 2017 11:45:20 -0700 (PDT) From: Eric Biggers To: linux-fscrypt@vger.kernel.org Cc: "Theodore Y . Ts'o" , Jaegeuk Kim , linux-f2fs-devel@lists.sourceforge.net, linux-ext4@vger.kernel.org, linux-mtd@lists.infradead.org, Gwendal Grignou , hashimoto@chromium.org, kinaba@chromium.org, Eric Biggers Subject: [PATCH] fscrypt: correct collision claim for digested names Date: Mon, 1 May 2017 11:43:32 -0700 Message-Id: <20170501184332.37532-1-ebiggers3@gmail.com> X-Mailer: git-send-email 2.13.0.rc0.306.g87b477812d-goog Sender: linux-fscrypt-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-fscrypt@vger.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP From: Eric Biggers 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 --- 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;