linux-ext4 - Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

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: <20171208214213.GA104193@gmail.com>
Date:   Fri, 8 Dec 2017 13:42:13 -0800
From:   Eric Biggers <ebiggers3@...il.com>
To:     Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc:     "Jason A. Donenfeld" <Jason@...c4.com>,
        linux-fscrypt@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        linux-mtd@...ts.infradead.org, linux-fsdevel@...r.kernel.org,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Jaegeuk Kim <jaegeuk@...nel.org>,
        Michael Halcrow <mhalcrow@...gle.com>,
        Paul Crowley <paulcrowley@...gle.com>,
        Martin Willi <martin@...ongswan.org>,
        David Gstir <david@...ma-star.at>,
        Eric Biggers <ebiggers@...gle.com>
Subject: Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption

On Fri, Dec 08, 2017 at 07:20:43AM +0000, Ard Biesheuvel wrote:
> On 8 December 2017 at 02:51, Jason A. Donenfeld <Jason@...c4.com> wrote:
> > Hi Eric,
> >
> > Nice to see more use of ChaCha20. However...
> >
> > Can we skip over the "sort of worse than XTS, but not having _real_
> > authentication sucks anyway in either case, so whatever" and move
> > directly to, "linux finally supports authenticated encryption for disk
> > encryption!"?
> 
> Ehm, it doesn't? This is plain ChaCha20, not any AEAD variant.
> 
> > This would be a big deal and would actually be a
> > noticeable security improvement, instead of a potentially dubious step
> > sidewaysbackish.
> >
> 
> It is actually dubious, given the large scale reuse of IVs with a
> stream cipher. I do suppose though that using an AEAD variant would at
> least catch any attacks involving flipping ciphertext bits resulting
> in plaintext bits being flipped at the same offset (but file updates
> would still be visible in the clear)
> 

It *is* dubious, but it would be a replacement for No Encryption, not a
replacement for AES.  AES would continue to be required on devices that can do
AES fast enough.  This would only be for devices that do not meet the AES
performance bar, so their status quo is No Encryption.  I know, it is fun to
poke holes in bad crypto, but much less interesting to poke holes in "no crypto"
:-)

We can't use authenticated encryption for the same reason we can't use random or
sequential nonces: there is nowhere to store the additional metadata
(authentication tag and nonce) per filesystem block *and* have it updated
atomically with respect to the contents of said block.  Copy-on-write
filesystems such as btrfs or bcachefs can do it.  Traditional filesystems
cannot.  F2FS comes closer than EXT4 since F2FS is based on a log-structured
filesystem, but only partially; for one, it still updates data in-place
sometimes.  This is not a new problem; this is also the reason why we haven't
been able to add AES-GCM support yet.

Authentication aside, the greater problem here is the IV reuse.  Unfortunately
it actually will likely be even worse than we thought originally, because this
would be used on flash storage that does wear leveling, and likely also with
F2FS which often doesn't overwrite data in-place.  So even under the "single
point-in-time permanent offline compromise" threat model it may not be good
enough.  We are going to spend some more time investigating alternatives, but
unfortunately there are not many.

Eric