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.

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?

Jeff

On Thu, Dec 7, 2017 at 8:38 PM, Eric Biggers [off-list ref] wrote:

From: Eric Biggers <redacted>

fscrypt currently only supports AES encryption.  However, many low-end
mobile devices still use older CPUs such as ARMv7, which do not support
the AES instructions (the ARMv8 Cryptography Extensions).  This results
in very poor AES performance, even if the NEON bit-sliced implementation
is used.  Roughly 20-40 MB/s is a typical number, in comparison to
300-800 MB/s on CPUs that support the AES instructions.  Switching from
AES-256 to AES-128 only helps by about 30%.

The result is that vendors don't enable encryption on these devices,
leaving users unprotected.

A performance difference of similar magnitude can also be observed on
x86, between CPUs with and without the AES-NI instruction set.

This patch provides an alternative to AES by updating fscrypt to support
the ChaCha20 stream cipher (RFC7539) for contents encryption.  ChaCha20
was designed to have a large security margin, to be efficient on
general-purpose CPUs without dedicated instructions, and to be
vectorizable.  It is already supported by the Linux crypto API,
including a vectorized implementation for ARM using NEON instructions,
and vectorized implementations for x86 using SSSE3 or AVX2 instructions.

On 32-bit ARM processors with NEON support, ChaCha20 is about 3.2 times
faster than AES-128-XTS (chacha20-neon vs. xts-aes-neonbs).  Without
NEON support, ChaCha20 is about 1.5 times as fast (chacha20-generic vs.
xts(aes-asm)).  The improvement over AES-256-XTS is even greater.

Note that stream ciphers are not an ideal choice for disk encryption,
since each data block has to be encrypted with the same IV each time it
is overwritten.  Consequently, an adversary who observes the ciphertext
both before and after a write can trivially recover the keystream if
they can guess one of the plaintexts.  Moreover, an adversary who can
write to the ciphertext can flip arbitrary bits in the plaintext, merely
by flipping the corresponding bits in the ciphertext.  A block cipher
operating in the XTS or CBC-ESSIV mode provides some protection against
these types of attacks -- albeit not full protection, which would at
minimum require the use an authenticated encryption mode with nonces.

Unfortunately, we are unaware of any block cipher which performs as well
as ChaCha20, has a similar or greater security margin, and has been
subject to as much public security analysis.  We do not consider Speck
to be a viable alternative at this time.

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.

We offer ChaCha20 rather than the reduced-round variants ChaCha8 or
ChaCha12 because ChaCha20 has a much higher security margin, and we are
primarily targeting CPUs where ChaCha20 is fast enough, in particular
CPUs that have vector instructions such as NEON or SSSE3.  Also, the
crypto API currently only supports ChaCha20.  Still, if ChaCha8 and/or
ChaCha12 support were to be added to the crypto API, it would be
straightforward to support them in fscrypt too.

Currently, stream ciphers cannot be used for filenames encryption with
fscrypt because all filenames in a directory have to be encrypted with
the same IV.  Therefore, we offer ChaCha20 for contents encryption only.
Filenames encryption still must use AES-256-CTS-CBC.  This is acceptable
because filenames encryption is not as performance-critical as contents
encryption.

...