On Wed, Feb 14, 2018 at 10:42:18AM -0800, Eric Biggers wrote: > Hello, > > This series adds Speck support to the crypto API, including the Speck128 > and Speck64 variants. Speck is a lightweight block cipher that can be > much faster than AES on processors that don't have AES instructions. > > We are planning to offer Speck-XTS (probably Speck128/256-XTS) as an > option for dm-crypt and fscrypt on Android, for low-end mobile devices > with older CPUs such as ARMv7 which don't have the Cryptography > Extensions. Currently, such devices are unencrypted because AES is not > fast enough, even when the NEON bit-sliced implementation of AES is > used. Other AES alternatives such as Twofish, Threefish, Camellia, > CAST6, and Serpent aren't fast enough either; it seems that only a > modern ARX cipher can provide sufficient performance on these devices. > > This is a replacement for our original proposal > (https://patchwork.kernel.org/patch/10101451/) which was to offer > ChaCha20 for these devices. However, the use of a stream cipher for > disk/file encryption with no space to store nonces would have been much > more insecure than we thought initially, given that it would be used on > top of flash storage as well as potentially on top of F2FS, neither of > which is guaranteed to overwrite data in-place. > > Speck has been somewhat controversial due to its origin. Nevertheless, > it has a straightforward design (it's an ARX cipher), and it appears to > be the leading software-optimized lightweight block cipher currently, > with the most cryptanalysis. It's also easy to implement without side > channels, unlike AES. Moreover, we only intend Speck to be used when > the status quo is no encryption, due to AES not being fast enough. > > We've also considered a novel length-preserving encryption mode based on > ChaCha20 and Poly1305. While theoretically attractive, such a mode > would be a brand new crypto construction and would be more complicated > and difficult to implement efficiently in comparison to Speck-XTS. > > Thus, patch 1 adds a generic implementation of Speck, and the following > patches add a 32-bit ARM NEON implementation of Speck-XTS. The > NEON-accelerated implementation is much faster than the generic > implementation and therefore is the implementation that would primarily > be used in practice on the devices we are targeting. > > There is no AArch64 implementation included, since most such CPUs have > the Cryptography Extensions, allowing the use of AES. An AArch64 > implementation can be added later if there is interest though. > > Changed since v2: > > - Fix __speck64_xts_crypt() to work on big endian CPUs. > > Changed since v1: > > - Use the word order recommended by the Speck authors. All test > vectors were updated. > > Eric Biggers (5): > crypto: add support for the Speck block cipher > crypto: speck - export common helpers > crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS > crypto: speck - add test vectors for Speck128-XTS > crypto: speck - add test vectors for Speck64-XTS > > arch/arm/crypto/Kconfig | 6 + > arch/arm/crypto/Makefile | 2 + > arch/arm/crypto/speck-neon-core.S | 432 +++++++++ > arch/arm/crypto/speck-neon-glue.c | 288 ++++++ > crypto/Kconfig | 14 + > crypto/Makefile | 1 + > crypto/speck.c | 307 ++++++ > crypto/testmgr.c | 36 + > crypto/testmgr.h | 1486 +++++++++++++++++++++++++++++ > include/crypto/speck.h | 62 ++ > 10 files changed, 2634 insertions(+) > create mode 100644 arch/arm/crypto/speck-neon-core.S > create mode 100644 arch/arm/crypto/speck-neon-glue.c > create mode 100644 crypto/speck.c > create mode 100644 include/crypto/speck.h All applied. Thanks. -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
