Date:   Sun, 20 May 2018 20:56:57 -0400
From:   "Theodore Y. Ts'o" <tytso@....edu>
To:     Eric Biggers <ebiggers@...gle.com>
Cc:     linux-fscrypt@...r.kernel.org, linux-crypto@...r.kernel.org,
        linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
        linux-mtd@...ts.infradead.org,
        Paul Crowley <paulcrowley@...gle.com>,
        Patrik Torstensson <totte@...gle.com>,
        Greg Kaiser <gkaiser@...gle.com>,
        Michael Halcrow <mhalcrow@...gle.com>,
        "Jason A . Donenfeld" <Jason@...c4.com>,
        Samuel Neves <samuel.c.p.neves@...il.com>,
        Jeffrey Walton <noloader@...il.com>
Subject: Re: [PATCH v2] fscrypt: add Speck128/256 support

On Mon, May 07, 2018 at 05:22:08PM -0700, Eric Biggers wrote:
> fscrypt currently only supports AES encryption.  However, many low-end
> mobile devices have older CPUs that don't have AES instructions, e.g.
> the ARMv8 Cryptography Extensions.  Currently, user data on such devices
> is not encrypted at rest because AES is too slow, even when the NEON
> bit-sliced implementation of AES is used.  Unfortunately, it is
> infeasible to encrypt these devices at all when AES is the only option.
> 
> Therefore, this patch updates fscrypt to support the Speck block cipher,
> which was recently added to the crypto API.  The C implementation of
> Speck is not especially fast, but Speck can be implemented very
> efficiently with general-purpose vector instructions, e.g. ARM NEON.
> For example, on an ARMv7 processor, we measured the NEON-accelerated
> Speck128/256-XTS at 69 MB/s for both encryption and decryption, while
> AES-256-XTS with the NEON bit-sliced implementation was only 22 MB/s
> encryption and 19 MB/s decryption.
> 
> There are multiple variants of Speck.  This patch only adds support for
> Speck128/256, which is the variant with a 128-bit block size and 256-bit
> key size -- the same as AES-256.  This is believed to be the most secure
> variant of Speck, and it's only about 6% slower than Speck128/128.
> Speck64/128 would be at least 20% faster because it has 20% rounds, and
> it can be even faster on CPUs that can't efficiently do the 64-bit
> operations needed for Speck128.  However, Speck64's 64-bit block size is
> not preferred security-wise.  ARM NEON also supports the needed 64-bit
> operations even on 32-bit CPUs, resulting in Speck128 being fast enough
> for our targeted use cases so far.
> 
> The chosen modes of operation are XTS for contents and CTS-CBC for
> filenames.  These are the same modes of operation that fscrypt defaults
> to for AES.  Note that as with the other fscrypt modes, Speck will not
> be used unless userspace chooses to use it.  Nor are any of the existing
> modes (which are all AES-based) being removed, of course.
> 
> We intentionally don't make CONFIG_FS_ENCRYPTION select
> CONFIG_CRYPTO_SPECK, so people will have to enable Speck support
> themselves if they need it.  This is because we shouldn't bloat the
> FS_ENCRYPTION dependencies with every new cipher, especially ones that
> aren't recommended for most users.  Moreover, CRYPTO_SPECK is just the
> generic implementation, which won't be fast enough for many users; in
> practice, they'll need to enable CRYPTO_SPECK_NEON to get acceptable
> performance.
> 
> More details about our choice of Speck can be found in our patches that
> added Speck to the crypto API, and the follow-on discussion threads.
> We're planning a publication that explains the choice in more detail.
> But briefly, we can't use ChaCha20 as we previously proposed, since it
> would be insecure to use a stream cipher in this context, with potential
> IV reuse during writes on f2fs and/or on wear-leveling flash storage.
> 
> We also evaluated many other lightweight and/or ARX-based block ciphers
> such as Chaskey-LTS, RC5, LEA, CHAM, Threefish, RC6, NOEKEON, SPARX, and
> XTEA.  However, all had disadvantages vs. Speck, such as insufficient
> performance with NEON, much less published cryptanalysis, or an
> insufficient security level.  Various design choices in Speck make it
> perform better with NEON than competing ciphers while still having a
> security margin similar to AES, and in the case of Speck128 also the
> same available security levels.  Unfortunately, Speck does have some
> political baggage attached -- it's an NSA designed cipher, and was
> rejected from an ISO standard (though for context, as far as I know none
> of the above-mentioned alternatives are ISO standards either).
> Nevertheless, we believe it is a good solution to the problem from a
> technical perspective.
> 
> Certain algorithms constructed from ChaCha or the ChaCha permutation,
> such as MEM (Masked Even-Mansour) or HPolyC, may also meet our
> performance requirements.  However, these are new constructions that
> need more time to receive the cryptographic review and acceptance needed
> to be confident in their security.  HPolyC hasn't been published yet,
> and we are concerned that MEM makes stronger assumptions about the
> underlying permutation than the ChaCha stream cipher does.  In contrast,
> the XTS mode of operation is relatively well accepted, and Speck has
> over 70 cryptanalysis papers.  Of course, these ChaCha-based algorithms
> can still be added later if they become ready.
> 
> The best known attack on Speck128/256 is a differential cryptanalysis
> attack on 25 of 34 rounds with 2^253 time complexity and 2^125 chosen
> plaintexts, i.e. only marginally faster than brute force.  There is no
> known attack on the full 34 rounds.
> 
> Signed-off-by: Eric Biggers <ebiggers@...gle.com>

Applied, thanks.

						- Ted

Powered by blists - more mailing lists