> On 08.12.2017, at 03:51, Jason A. Donenfeld <Jason@xxxxxxxxx> 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/
