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
