linux-ext4 - Re: [PATCH] fscrypto: make XTS tweak initialization endian-independent

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20161006011714.GT27872@dastard>
Date:   Thu, 6 Oct 2016 12:17:15 +1100
From:   Dave Chinner <david@...morbit.com>
To:     Richard Weinberger <richard@....at>
Cc:     Michael Halcrow <mhalcrow@...gle.com>,
        David Gstir <david@...ma-star.at>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        Theodore Ts'o <tytso@....edu>, jaegeuk@...nel.org,
        Eric Biggers <ebiggers@...gle.com>,
        Anand Jain <anand.jain@...cle.com>,
        Tyler Hicks <tyhicks@...onical.com>
Subject: Re: [PATCH] fscrypto: make XTS tweak initialization
 endian-independent

On Wed, Oct 05, 2016 at 11:14:55PM +0200, Richard Weinberger wrote:
> Michael,
> 
> On 05.10.2016 20:44, Richard Weinberger wrote:
> > Well, let's focus first on file contents.
> > We have already the fscrypo framework.
> > 
> > What you suggest is completely different from what we have now.
> 
> To clarify that, I'm not saying that meta-data or block level authentication
> is a bad idea. But let's start with small steps and consider file contents
> authentication first. Of course this has some attack vectors but these
> can be documented and for many use case these are acceptable.

This is the sanest approach, because encrypting filesystem internal
metadata may have some unintended consequences. e.g being unable to
perform forensic analysis of corruption or data loss events, or an
inability for tools like fsck to work without also implementing all
the encryption code in userspace and being provided with all the
keys needed to decrypt the metadata.

i.e. it's not just the kernel code we have to consider here when
discussing this level of encryption in filesystems - the impact
on the entire support ecosystem needs to be considered. A weakness
in a fsck tool will be just as serious as a weakness in the kernel
code, and there's a much larger amount of widely dispersed code that
would need to be encryption enabled by going down this path.

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html