All of lore.kernel.org
 help / color / mirror / Atom feed
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Eric Biggers <ebiggers@google.com>
Cc: Jeffrey Walton <noloader@gmail.com>,
	Greg Kaiser <gkaiser@google.com>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Michael Halcrow <mhalcrow@google.com>,
	Patrik Torstensson <totte@google.com>,
	Alex Cope <alexcope@google.com>,
	Paul Lawrence <paullawrence@google.com>,
	linux-fscrypt@vger.kernel.org, linux-crypto@vger.kernel.org,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-arm-kernel@lists.infradead.org,
	Paul Crowley <paulcrowley@google.com>
Subject: Re: [PATCH v3 0/5] crypto: Speck support
Date: Thu, 22 Feb 2018 23:13:24 +0800	[thread overview]
Message-ID: <20180222151324.GJ29815@gondor.apana.org.au> (raw)
In-Reply-To: <20180214184223.254359-1-ebiggers@google.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: Herbert Xu <herbert@gondor.apana.org.au>
To: Eric Biggers <ebiggers@google.com>
Cc: linux-crypto@vger.kernel.org, linux-fscrypt@vger.kernel.org,
	linux-arm-kernel@lists.infradead.org,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Jeffrey Walton <noloader@gmail.com>,
	Paul Crowley <paulcrowley@google.com>,
	Patrik Torstensson <totte@google.com>,
	Greg Kaiser <gkaiser@google.com>,
	Paul Lawrence <paullawrence@google.com>,
	Michael Halcrow <mhalcrow@google.com>,
	Alex Cope <alexcope@google.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [PATCH v3 0/5] crypto: Speck support
Date: Thu, 22 Feb 2018 23:13:24 +0800	[thread overview]
Message-ID: <20180222151324.GJ29815@gondor.apana.org.au> (raw)
In-Reply-To: <20180214184223.254359-1-ebiggers@google.com>

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

WARNING: multiple messages have this Message-ID (diff)
From: herbert@gondor.apana.org.au (Herbert Xu)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 0/5] crypto: Speck support
Date: Thu, 22 Feb 2018 23:13:24 +0800	[thread overview]
Message-ID: <20180222151324.GJ29815@gondor.apana.org.au> (raw)
In-Reply-To: <20180214184223.254359-1-ebiggers@google.com>

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

  parent reply	other threads:[~2018-02-22 15:13 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-02-14 18:42 [PATCH v3 0/5] crypto: Speck support Eric Biggers
2018-02-14 18:42 ` Eric Biggers
2018-02-14 18:42 ` [PATCH v3 1/5] crypto: add support for the Speck block cipher Eric Biggers
2018-02-14 18:42   ` Eric Biggers
2018-02-14 18:42 ` [PATCH v3 2/5] crypto: speck - export common helpers Eric Biggers
2018-02-14 18:42   ` Eric Biggers
2018-02-14 18:42 ` [PATCH v3 3/5] crypto: arm/speck - add NEON-accelerated implementation of Speck-XTS Eric Biggers
2018-02-14 18:42   ` Eric Biggers
2018-06-16 22:40   ` Stefan Agner
2018-06-16 22:40     ` Stefan Agner
2018-06-16 22:40     ` Stefan Agner
2018-06-17  9:30     ` Ard Biesheuvel
2018-06-17  9:30       ` Ard Biesheuvel
2018-06-17  9:30       ` Ard Biesheuvel
2018-06-17  9:40       ` Ard Biesheuvel
2018-06-17  9:40         ` Ard Biesheuvel
2018-06-17  9:40         ` Ard Biesheuvel
2018-06-17 10:41         ` Stefan Agner
2018-06-17 10:41           ` Stefan Agner
2018-06-17 10:41           ` Stefan Agner
2018-06-17 11:10           ` Ard Biesheuvel
2018-06-17 11:10             ` Ard Biesheuvel
2018-06-17 11:10             ` Ard Biesheuvel
2018-06-18 21:56             ` Eric Biggers
2018-06-18 21:56               ` Eric Biggers
2018-06-18 21:56               ` Eric Biggers
2018-06-18 22:04               ` Ard Biesheuvel
2018-06-18 22:04                 ` Ard Biesheuvel
2018-06-18 22:04                 ` Ard Biesheuvel
2018-02-14 18:42 ` [PATCH v3 4/5] crypto: speck - add test vectors for Speck128-XTS Eric Biggers
2018-02-14 18:42   ` Eric Biggers
2018-02-14 18:42 ` [PATCH v3 5/5] crypto: speck - add test vectors for Speck64-XTS Eric Biggers
2018-02-14 18:42   ` Eric Biggers
2018-02-22 15:13 ` Herbert Xu [this message]
2018-02-22 15:13   ` [PATCH v3 0/5] crypto: Speck support Herbert Xu
2018-02-22 15:13   ` Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180222151324.GJ29815@gondor.apana.org.au \
    --to=herbert@gondor.apana.org.au \
    --cc=alexcope@google.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=ebiggers@google.com \
    --cc=gkaiser@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=mhalcrow@google.com \
    --cc=noloader@gmail.com \
    --cc=paulcrowley@google.com \
    --cc=paullawrence@google.com \
    --cc=totte@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.