Message ID | 20220412172816.917723-1-nhuck@google.com (mailing list archive) |
---|---|
Headers | show |
Series | crypto: HCTR2 support | expand |
On Tue, 12 Apr 2022 at 19:28, Nathan Huckleberry <nhuck@google.com> wrote: > > 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, a templated implementation > of HCTR2, and an fscrypt policy for using HCTR2 for filename encryption. > > Changes in v4: > * Small style fixes in generic POLYVAL and XCTR > * Move HCTR2 hash exporting/importing to helper functions > * Rewrite montgomery reduction for x86-64 POLYVAL > * Rewrite partial block handling for x86-64 POLYVAL > * Optimize x86-64 POLYVAL loop handling > * Remove ahash wrapper from x86-64 POLYVAL > * Add simd-unavailable handling to x86-64 POLYVAL > * Rewrite montgomery reduction for ARM64 POLYVAL > * Rewrite partial block handling for ARM64 POLYVAL > * Optimize ARM64 POLYVAL loop handling > * Remove ahash wrapper from ARM64 POLYVAL > * Add simd-unavailable handling to ARM64 POLYVAL > > Changes in v3: > * Improve testvec coverage for XCTR, POLYVAL and HCTR2 > * Fix endianness bug in xctr.c > * Fix alignment issues in polyval-generic.c > * Optimize hctr2.c by exporting/importing hash states > * Fix blockcipher name derivation in hctr2.c > * Move x86-64 XCTR implementation into aes_ctrby8_avx-x86_64.S > * Reuse ARM64 CTR mode tail handling in ARM64 XCTR > * Fix x86-64 POLYVAL comments > * Fix x86-64 POLYVAL key_powers type to match asm > * Fix ARM64 POLYVAL comments > * Fix ARM64 POLYVAL key_powers type to match asm > * Add XTS + HCTR2 policy to fscrypt > > Nathan Huckleberry (8): > 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 > fscrypt: Add HCTR2 support for filename encryption > This is looking very good, thanks for your continued efforts on this. Once Eric's feeback has been addressed, feel free to add Reviewed-by: Ard Biesheuvel <ardb@kernel.org> to the series. > Documentation/filesystems/fscrypt.rst | 19 +- > arch/arm64/crypto/Kconfig | 10 +- > arch/arm64/crypto/Makefile | 3 + > arch/arm64/crypto/aes-glue.c | 65 +- > arch/arm64/crypto/aes-modes.S | 134 ++ > arch/arm64/crypto/polyval-ce-core.S | 366 ++++++ > arch/arm64/crypto/polyval-ce-glue.c | 240 ++++ > arch/x86/crypto/Makefile | 3 + > arch/x86/crypto/aes_ctrby8_avx-x86_64.S | 233 ++-- > arch/x86/crypto/aesni-intel_asm.S | 70 ++ > arch/x86/crypto/aesni-intel_glue.c | 89 ++ > arch/x86/crypto/polyval-clmulni_asm.S | 333 +++++ > arch/x86/crypto/polyval-clmulni_glue.c | 234 ++++ > crypto/Kconfig | 40 +- > crypto/Makefile | 3 + > crypto/hctr2.c | 616 +++++++++ > crypto/polyval-generic.c | 214 ++++ > crypto/tcrypt.c | 10 + > crypto/testmgr.c | 20 + > crypto/testmgr.h | 1536 +++++++++++++++++++++++ > crypto/xctr.c | 191 +++ > fs/crypto/fscrypt_private.h | 2 +- > fs/crypto/keysetup.c | 7 + > fs/crypto/policy.c | 4 + > include/crypto/polyval.h | 17 + > include/uapi/linux/fscrypt.h | 3 +- > tools/include/uapi/linux/fscrypt.h | 3 +- > 27 files changed, 4376 insertions(+), 89 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/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.1178.g4f1659d476-goog >