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-prev] [day] [month] [year] [list]
Date:   Mon, 11 Dec 2017 17:11:41 +0100
From:   David Gstir <david@...ma-star.at>
To:     "Jason A. Donenfeld" <Jason@...c4.com>
Cc:     Eric Biggers <ebiggers3@...il.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>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Eric Biggers <ebiggers@...gle.com>,
        Richard Weinberger <richard@....at>
Subject: Re: [PATCH] fscrypt: add support for ChaCha20 contents encryption


> On 08.12.2017, at 03: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!"? This would be a big deal and would actually be a
> noticeable security improvement, instead of a potentially dubious step
> sidewaysbackish.

Out of curiosity, does anybody know of any specific attacks that authenticated
encryption for disk encryption would solve as opposed to just using encryption
with AES-XTS?

To my knowledge the XTS mode is frowned upon [1], but I don't know of any
serious flaws that would eg. allow an attacker to modify file contents
without a *serious* amount of effort. CBC is another story though [2].

Don't get me wrong, I'd like to have authenticated encryption too.
In fact we are currently working on a concept for adding authentication to
UBIFS (I'll share more details as soon as its in a presentable state).
However, the reason for this is mainly because UBIFS does *not* operate on
the block layer, so dm-integrity/dm-verity is not an option and fscrypt
only protects the confidentiality of file contents and filenames.
This means that the filesystem index is unprotected which makes it rather
easy to move files around - eg. replace /bin/bash with something completely
different without knowing the fscrypt master key or any derived key.

For the general use case though (eg. securing *really important* files on my desktop),
I'd use authenticated encryption at a higher layer to get more flexibility
to eg. easily use explicit IVs over implicit ones derived from block/sector
number. But maybe there are some uses cases I didn't think of just now... :)

David

[1] https://sockpuppet.org/blog/2014/04/30/you-dont-want-xts/
[2] http://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ