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 <herb...@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Reply via email to