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

[Eric Biggers <ebiggers3@gmail.com>]

On Fri, Dec 08, 2017 at 07:48:54PM -0500, Jeffrey Walton wrote:
> > Still, a stream cipher is sufficient to protect data confidentiality in
> > the event of a single point-in-time permanent offline compromise of the
> > disk, which currently is the primary threat model for fscrypt.  Thus,
> > when the alternative is quite literally *no encryption*, we might as
> > well use a stream cipher.
> 
> The "single point in time" requirement is kind of interesting. I
> believe you are saying the scheme lacks semantic security.

Well, it is semantically secure when looking at encryptions/decryptions done in
the context of different blocks (different IVs) but not semantically secure when
looking at encryptions/decryptions done in the context of the same block (same
IV).  But in that regard it is the same as the other modes such as AES-XTS or
AES-CBC.  So I think you are missing the point, which is that a stream cipher
fails more catastrophically than the other modes when IVs are reused.

> 
> Forgive my ignorance... Does that mean this cipher should not be used
> when backups are in effect; or sync'ing to <insert favorite cloud
> provider> happens?

Normally backup or sync software will operate on the plaintext, which makes
whatever type of filesystem-level or disk encryption you happen to be using
irrelevant.  But at a more abstract level, intentional copies (in addition to
"unintentional" copies that may be done by the filesystem or flash storage) are
certainly a way that you could end up with multiple ciphertexts for the same
block in existence at the same time, so that would indeed need to be accounted
for in the assumptions.

Eric