From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Biggers Subject: Re: Proposal: Yet another possible fs-verity interface Date: Tue, 12 Feb 2019 10:42:10 -0800 Message-ID: <20190212184209.GA3373@gmail.com> References: <20190207031101.GA7387@mit.edu> <1549807615.12743.109.camel@linux.ibm.com> <20190212053123.GR23000@mit.edu> <1549976812.12743.225.camel@linux.ibm.com> <20190212172433.GT23000@mit.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from [172.30.20.202] (helo=mx.sourceforge.net) by sfs-ml-2.v29.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gtd0h-0007Mb-5J for linux-f2fs-devel@lists.sourceforge.net; Tue, 12 Feb 2019 18:42:23 +0000 Received: from mail.kernel.org ([198.145.29.99]) by sfi-mx-3.v28.lw.sourceforge.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1) id 1gtd0e-003PJo-Nl for linux-f2fs-devel@lists.sourceforge.net; Tue, 12 Feb 2019 18:42:23 +0000 Content-Disposition: inline In-Reply-To: <20190212172433.GT23000@mit.edu> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linux-f2fs-devel-bounces@lists.sourceforge.net To: "Theodore Y. Ts'o" Cc: James Bottomley , "Darrick J. Wong" , Dave Chinner , Mimi Zohar , linux-f2fs-devel@lists.sourceforge.net, Christoph Hellwig , linux-fscrypt@vger.kernel.org, linux-fsdevel , linux-ext4@vger.kernel.org, Linus Torvalds On Tue, Feb 12, 2019 at 12:24:33PM -0500, Theodore Y. Ts'o wrote: > = > > > > The existing file hashes included in the measurement list and the > > > > audit log, are currently being used for remote attestation, forensi= cs > > > > and security analytics. > > = > > Again, the context for this comment was Linus' suggestion "each level > > of the merkle tree needs to have a hash seeding thing or whatever." > > Up to this point, I had assumed the Merkle tree file root hash could > > be used as an identifier, similar to the file hash.=A0=A0With his > > suggestion, it sounds like the Merkle tree file root hash would be > > system dependent, making it useless for the above usages. > = > Yeah, I have no idea what Linus was talking about there. The only > thing that really makes sense is that if you don't have any > file-system place to store a seed, you don't use a seed for the Merkle > tree, and for a given set of bytes, the Merkle root hash is the same. > So it's basically an expensive to calculate crypto checksum, as I said. > = I think there's confusion due to the use of the phrase "Merkle tree root ha= sh". Linus's point was: > Now, since I assume that only the merkle tree root hash would be > returned by the "enable merkle tree" operation (so that the code > enabling it can verify that the hash matches the expected value), you > do have to worry about the preimage attack, and make sure that you > can't fool the hashing by making the (bad) file contents themselves be > just the hashes of the (good) blocks. So each level of the merkle tree > needs to have a hash seeding thing or whatever. This is already taken into account in the original design. The file hash reported by fs-verity is *not* the Merkle tree root hash directly, but rath= er a hash of the Merkle tree root hash and additional metadata in the fsverity_descriptor including the file size in bytes. This resulting hash = is referred to in the code, documentation, etc. as the "fs-verity file measure= ment". Thus you can't fool the hashing in the way that Linus mentioned, because the file size is included in the hash too. And I don't expect this part of the design should change, even if we change the API. It's been difficult to get people to start saying "fs-verity file measureme= nt" rather than "Merkle tree root hash", though, so if anyone has a suggestion = for a better name it would be appreciated. An earlier name was "fs-verity root h= ash", but I thought that would too easily be confused with the Merkle tree root h= ash. fs-verity does support a salt as well, but it's optional and isn't needed to prevent preimage attacks, assuming the user chose a strong cryptographic ha= sh function such as SHA-256 or SHA-512. - Eric