All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Huckleberry <nhuck@google.com>
To: linux-crypto@vger.kernel.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	linux-arm-kernel@lists.infradead.org,
	Paul Crowley <paulcrowley@google.com>,
	Eric Biggers <ebiggers@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	Ard Biesheuvel <ardb@kernel.org>,
	Nathan Huckleberry <nhuck@google.com>
Subject: [RFC PATCH v2 0/7] crypto: HCTR2 support
Date: Thu, 10 Feb 2022 23:28:05 +0000	[thread overview]
Message-ID: <20220210232812.798387-1-nhuck@google.com> (raw)

HCTR2 is a length-preserving encryption mode that is efficient on
processors with instructions to accelerate AES and carryless
multiplication, e.g. x86 processors with AES-NI and CLMUL, and ARM
processors with the ARMv8 Crypto Extensions.

HCTR2 is specified in https://ia.cr/2021/1441 "Length-preserving
encryption with HCTR2" which shows that if AES is secure and HCTR2 is
instantiated with AES, then HCTR2 is secure.  Reference code and test
vectors are at https://github.com/google/hctr2.

As a length-preserving encryption mode, HCTR2 is suitable for applications
such as storage encryption where ciphertext expansion is not possible, and
thus authenticated encryption cannot be used.  Currently, such
applications usually use XTS, or in some cases Adiantum.  XTS has the
disadvantage that it is a narrow-block mode: a bitflip will only change 16
bytes in the resulting ciphertext or plaintext.  This reveals more
information to an attacker than necessary.

HCTR2 is a wide-block mode, so it provides a stronger security property: a
bitflip will change the entire message.  HCTR2 is somewhat similar to
Adiantum, which is also a wide-block mode.  However, HCTR2 is designed to
take advantage of existing crypto instructions, while Adiantum targets
devices without such hardware support.  Adiantum is also designed with
longer messages in mind, while HCTR2 is designed to be efficient even on
short messages.

The first intended use of this mode in the kernel is for the encryption of
filenames, where for efficiency reasons encryption must be fully
deterministic (only one ciphertext for each plaintext) and the existing
CBC solution leaks more information than necessary for filenames with
common prefixes.

HCTR2 uses two passes of an ε-almost-∆-universal hash function called
POLYVAL and one pass of a block cipher mode called XCTR.  POLYVAL is a
polynomial hash designed for efficiency on modern processors and was
originally specified for use in AES-GCM-SIV (RFC 8452).  XCTR mode is a
variant of CTR mode that is more efficient on little-endian machines.

This patchset adds HCTR2 to Linux's crypto API, including generic
implementations of XCTR and POLYVAL, hardware accelerated implementations
of XCTR and POLYVAL for both x86-64 and ARM64, and a templated
implementation of HCTR2.

Nathan Huckleberry (7):
  crypto: xctr - Add XCTR support
  crypto: polyval - Add POLYVAL support
  crypto: hctr2 - Add HCTR2 support
  crypto: x86/aesni-xctr: Add accelerated implementation of XCTR
  crypto: arm64/aes-xctr: Add accelerated implementation of XCTR
  crypto: x86/polyval: Add PCLMULQDQ accelerated implementation of
    POLYVAL
  crypto: arm64/polyval: Add PMULL accelerated implementation of POLYVAL

 arch/arm64/crypto/Kconfig                |   11 +-
 arch/arm64/crypto/Makefile               |    3 +
 arch/arm64/crypto/aes-glue.c             |   72 +-
 arch/arm64/crypto/aes-modes.S            |  130 ++
 arch/arm64/crypto/polyval-ce-core.S      |  405 ++++++
 arch/arm64/crypto/polyval-ce-glue.c      |  365 ++++++
 arch/x86/crypto/Makefile                 |    5 +-
 arch/x86/crypto/aes_xctrby8_avx-x86_64.S |  529 ++++++++
 arch/x86/crypto/aesni-intel_asm.S        |   70 +
 arch/x86/crypto/aesni-intel_glue.c       |   89 ++
 arch/x86/crypto/polyval-clmulni_asm.S    |  414 ++++++
 arch/x86/crypto/polyval-clmulni_glue.c   |  365 ++++++
 crypto/Kconfig                           |   38 +
 crypto/Makefile                          |    3 +
 crypto/hctr2.c                           |  532 ++++++++
 crypto/polyval-generic.c                 |  199 +++
 crypto/tcrypt.c                          |   10 +
 crypto/testmgr.c                         |   20 +
 crypto/testmgr.h                         | 1500 ++++++++++++++++++++++
 crypto/xctr.c                            |  193 +++
 include/crypto/polyval.h                 |   22 +
 21 files changed, 4970 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/crypto/polyval-ce-core.S
 create mode 100644 arch/arm64/crypto/polyval-ce-glue.c
 create mode 100644 arch/x86/crypto/aes_xctrby8_avx-x86_64.S
 create mode 100644 arch/x86/crypto/polyval-clmulni_asm.S
 create mode 100644 arch/x86/crypto/polyval-clmulni_glue.c
 create mode 100644 crypto/hctr2.c
 create mode 100644 crypto/polyval-generic.c
 create mode 100644 crypto/xctr.c
 create mode 100644 include/crypto/polyval.h

-- 
2.35.1.265.g69c8d7142f-goog


WARNING: multiple messages have this Message-ID (diff)
From: Nathan Huckleberry <nhuck@google.com>
To: linux-crypto@vger.kernel.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
	"David S. Miller" <davem@davemloft.net>,
	 linux-arm-kernel@lists.infradead.org,
	Paul Crowley <paulcrowley@google.com>,
	 Eric Biggers <ebiggers@kernel.org>,
	Sami Tolvanen <samitolvanen@google.com>,
	 Ard Biesheuvel <ardb@kernel.org>,
	Nathan Huckleberry <nhuck@google.com>
Subject: [RFC PATCH v2 0/7] crypto: HCTR2 support
Date: Thu, 10 Feb 2022 23:28:05 +0000	[thread overview]
Message-ID: <20220210232812.798387-1-nhuck@google.com> (raw)

HCTR2 is a length-preserving encryption mode that is efficient on
processors with instructions to accelerate AES and carryless
multiplication, e.g. x86 processors with AES-NI and CLMUL, and ARM
processors with the ARMv8 Crypto Extensions.

HCTR2 is specified in https://ia.cr/2021/1441 "Length-preserving
encryption with HCTR2" which shows that if AES is secure and HCTR2 is
instantiated with AES, then HCTR2 is secure.  Reference code and test
vectors are at https://github.com/google/hctr2.

As a length-preserving encryption mode, HCTR2 is suitable for applications
such as storage encryption where ciphertext expansion is not possible, and
thus authenticated encryption cannot be used.  Currently, such
applications usually use XTS, or in some cases Adiantum.  XTS has the
disadvantage that it is a narrow-block mode: a bitflip will only change 16
bytes in the resulting ciphertext or plaintext.  This reveals more
information to an attacker than necessary.

HCTR2 is a wide-block mode, so it provides a stronger security property: a
bitflip will change the entire message.  HCTR2 is somewhat similar to
Adiantum, which is also a wide-block mode.  However, HCTR2 is designed to
take advantage of existing crypto instructions, while Adiantum targets
devices without such hardware support.  Adiantum is also designed with
longer messages in mind, while HCTR2 is designed to be efficient even on
short messages.

The first intended use of this mode in the kernel is for the encryption of
filenames, where for efficiency reasons encryption must be fully
deterministic (only one ciphertext for each plaintext) and the existing
CBC solution leaks more information than necessary for filenames with
common prefixes.

HCTR2 uses two passes of an ε-almost-∆-universal hash function called
POLYVAL and one pass of a block cipher mode called XCTR.  POLYVAL is a
polynomial hash designed for efficiency on modern processors and was
originally specified for use in AES-GCM-SIV (RFC 8452).  XCTR mode is a
variant of CTR mode that is more efficient on little-endian machines.

This patchset adds HCTR2 to Linux's crypto API, including generic
implementations of XCTR and POLYVAL, hardware accelerated implementations
of XCTR and POLYVAL for both x86-64 and ARM64, and a templated
implementation of HCTR2.

Nathan Huckleberry (7):
  crypto: xctr - Add XCTR support
  crypto: polyval - Add POLYVAL support
  crypto: hctr2 - Add HCTR2 support
  crypto: x86/aesni-xctr: Add accelerated implementation of XCTR
  crypto: arm64/aes-xctr: Add accelerated implementation of XCTR
  crypto: x86/polyval: Add PCLMULQDQ accelerated implementation of
    POLYVAL
  crypto: arm64/polyval: Add PMULL accelerated implementation of POLYVAL

 arch/arm64/crypto/Kconfig                |   11 +-
 arch/arm64/crypto/Makefile               |    3 +
 arch/arm64/crypto/aes-glue.c             |   72 +-
 arch/arm64/crypto/aes-modes.S            |  130 ++
 arch/arm64/crypto/polyval-ce-core.S      |  405 ++++++
 arch/arm64/crypto/polyval-ce-glue.c      |  365 ++++++
 arch/x86/crypto/Makefile                 |    5 +-
 arch/x86/crypto/aes_xctrby8_avx-x86_64.S |  529 ++++++++
 arch/x86/crypto/aesni-intel_asm.S        |   70 +
 arch/x86/crypto/aesni-intel_glue.c       |   89 ++
 arch/x86/crypto/polyval-clmulni_asm.S    |  414 ++++++
 arch/x86/crypto/polyval-clmulni_glue.c   |  365 ++++++
 crypto/Kconfig                           |   38 +
 crypto/Makefile                          |    3 +
 crypto/hctr2.c                           |  532 ++++++++
 crypto/polyval-generic.c                 |  199 +++
 crypto/tcrypt.c                          |   10 +
 crypto/testmgr.c                         |   20 +
 crypto/testmgr.h                         | 1500 ++++++++++++++++++++++
 crypto/xctr.c                            |  193 +++
 include/crypto/polyval.h                 |   22 +
 21 files changed, 4970 insertions(+), 5 deletions(-)
 create mode 100644 arch/arm64/crypto/polyval-ce-core.S
 create mode 100644 arch/arm64/crypto/polyval-ce-glue.c
 create mode 100644 arch/x86/crypto/aes_xctrby8_avx-x86_64.S
 create mode 100644 arch/x86/crypto/polyval-clmulni_asm.S
 create mode 100644 arch/x86/crypto/polyval-clmulni_glue.c
 create mode 100644 crypto/hctr2.c
 create mode 100644 crypto/polyval-generic.c
 create mode 100644 crypto/xctr.c
 create mode 100644 include/crypto/polyval.h

-- 
2.35.1.265.g69c8d7142f-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

             reply	other threads:[~2022-02-10 23:28 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-10 23:28 Nathan Huckleberry [this message]
2022-02-10 23:28 ` [RFC PATCH v2 0/7] crypto: HCTR2 support Nathan Huckleberry
2022-02-10 23:28 ` [RFC PATCH v2 1/7] crypto: xctr - Add XCTR support Nathan Huckleberry
2022-02-10 23:28   ` Nathan Huckleberry
2022-02-16 23:00   ` Eric Biggers
2022-02-16 23:00     ` Eric Biggers
2022-02-17  7:07     ` Arnd Bergmann
2022-02-17  7:07       ` Arnd Bergmann
2022-02-10 23:28 ` [RFC PATCH v2 2/7] crypto: polyval - Add POLYVAL support Nathan Huckleberry
2022-02-10 23:28   ` Nathan Huckleberry
2022-02-16 23:16   ` Eric Biggers
2022-02-16 23:16     ` Eric Biggers
2022-02-10 23:28 ` [RFC PATCH v2 3/7] crypto: hctr2 - Add HCTR2 support Nathan Huckleberry
2022-02-10 23:28   ` Nathan Huckleberry
2022-02-17  1:07   ` Eric Biggers
2022-02-17  1:07     ` Eric Biggers
2022-02-10 23:28 ` [RFC PATCH v2 4/7] crypto: x86/aesni-xctr: Add accelerated implementation of XCTR Nathan Huckleberry
2022-02-10 23:28   ` Nathan Huckleberry
2022-02-19  1:28   ` Eric Biggers
2022-02-19  1:28     ` Eric Biggers
2022-02-10 23:28 ` [RFC PATCH v2 5/7] crypto: arm64/aes-xctr: " Nathan Huckleberry
2022-02-10 23:28   ` Nathan Huckleberry
2022-02-11 11:48   ` Ard Biesheuvel
2022-02-11 11:48     ` Ard Biesheuvel
2022-02-11 20:30     ` Nathan Huckleberry
2022-02-11 20:30       ` Nathan Huckleberry
2022-02-12 10:08       ` Ard Biesheuvel
2022-02-12 10:08         ` Ard Biesheuvel
2022-02-10 23:28 ` [RFC PATCH v2 6/7] crypto: x86/polyval: Add PCLMULQDQ accelerated implementation of POLYVAL Nathan Huckleberry
2022-02-10 23:28   ` Nathan Huckleberry
2022-02-19  0:34   ` Eric Biggers
2022-02-19  0:34     ` Eric Biggers
2022-02-19  0:54     ` Eric Biggers
2022-02-19  0:54       ` Eric Biggers
2022-02-10 23:28 ` [RFC PATCH v2 7/7] crypto: arm64/polyval: Add PMULL " Nathan Huckleberry
2022-02-10 23:28   ` Nathan Huckleberry
2022-02-19  1:21   ` Eric Biggers
2022-02-19  1:21     ` Eric Biggers

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=20220210232812.798387-1-nhuck@google.com \
    --to=nhuck@google.com \
    --cc=ardb@kernel.org \
    --cc=davem@davemloft.net \
    --cc=ebiggers@kernel.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=paulcrowley@google.com \
    --cc=samitolvanen@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.