Hi Ard, On Sat, Oct 20, 2018 at 12:00:31PM +0800, Ard Biesheuvel wrote: > On 16 October 2018 at 01:54, Eric Biggers <ebiggers@xxxxxxxxxx> wrote: > > From: Eric Biggers <ebiggers@xxxxxxxxxx> > > > > Add a generic implementation of NHPoly1305, an ε-almost-∆-universal hash > > function used in the Adiantum encryption mode. > > > > CONFIG_NHPOLY1305 is not selectable by itself since there won't be any > > real reason to enable it without also enabling Adiantum support. > > > > Signed-off-by: Eric Biggers <ebiggers@xxxxxxxxxx> > > --- > > crypto/Kconfig | 5 + > > crypto/Makefile | 1 + > > crypto/nhpoly1305.c | 288 ++++++++ > > crypto/testmgr.c | 6 + > > crypto/testmgr.h | 1240 ++++++++++++++++++++++++++++++++++- > > include/crypto/nhpoly1305.h | 74 +++ > > 6 files changed, 1610 insertions(+), 4 deletions(-) > > create mode 100644 crypto/nhpoly1305.c > > create mode 100644 include/crypto/nhpoly1305.h > > > > diff --git a/crypto/Kconfig b/crypto/Kconfig > > index 4fa0a4a0e8615..431beca903623 100644 > > --- a/crypto/Kconfig > > +++ b/crypto/Kconfig > > @@ -493,6 +493,11 @@ config CRYPTO_KEYWRAP > > Support for key wrapping (NIST SP800-38F / RFC3394) without > > padding. > > > > +config CRYPTO_NHPOLY1305 > > + tristate > > + select CRYPTO_HASH > > + select CRYPTO_POLY1305 > > + > > comment "Hash modes" > > > > config CRYPTO_CMAC > > diff --git a/crypto/Makefile b/crypto/Makefile > > index 7e673f7c71107..87b86f221a2a2 100644 > > --- a/crypto/Makefile > > +++ b/crypto/Makefile > > @@ -84,6 +84,7 @@ obj-$(CONFIG_CRYPTO_LRW) += lrw.o > > obj-$(CONFIG_CRYPTO_XTS) += xts.o > > obj-$(CONFIG_CRYPTO_CTR) += ctr.o > > obj-$(CONFIG_CRYPTO_KEYWRAP) += keywrap.o > > +obj-$(CONFIG_CRYPTO_NHPOLY1305) += nhpoly1305.o > > obj-$(CONFIG_CRYPTO_GCM) += gcm.o > > obj-$(CONFIG_CRYPTO_CCM) += ccm.o > > obj-$(CONFIG_CRYPTO_CHACHA20POLY1305) += chacha20poly1305.o > > diff --git a/crypto/nhpoly1305.c b/crypto/nhpoly1305.c > > new file mode 100644 > > index 0000000000000..087ad7680dd62 > > --- /dev/null > > +++ b/crypto/nhpoly1305.c > > @@ -0,0 +1,288 @@ > > +// SPDX-License-Identifier: GPL-2.0 > > +/* > > + * NHPoly1305 - ε-almost-∆-universal hash function for Adiantum > > + * > > + * Copyright 2018 Google LLC > > + */ > > + > > +/* > > + * "NHPoly1305" is the main component of Adiantum hashing. > > + * Specifically, it is the calculation > > + * > > + * H_M ← Poly1305_{K_M}(NH_{K_N}(pad_{128}(M))) > > + * > > + * from the procedure in section A.5 of the Adiantum paper [1]. It is an > > + * ε-almost-∆-universal (εA∆U) hash function for equal-length inputs over > > + * Z/(2^{128}Z), where the "∆" operation is addition. It hashes 1024-byte > > + * chunks of the input with the NH hash function [2], reducing the input length > > + * by 32x. The resulting NH digests are evaluated as a polynomial in > > + * GF(2^{130}-5), like in the Poly1305 MAC [3]. Note that the polynomial > > + * evaluation by itself would suffice to achieve the εA∆U property; NH is used > > + * for performance since it's over twice as fast as Poly1305. > > + * > > + * This is *not* a cryptographic hash function; do not use it as such! > > + * > > + * [1] Adiantum: length-preserving encryption for entry-level processors > > + * (https://eprint.iacr.org/2018/720.pdf) > > + * [2] UMAC: Fast and Secure Message Authentication > > + * (https://fastcrypto.org/umac/umac_proc.pdf) > > + * [3] The Poly1305-AES message-authentication code > > + * (https://cr.yp.to/mac/poly1305-20050329.pdf) > > + */ > > + > > +#include <asm/unaligned.h> > > +#include <crypto/algapi.h> > > +#include <crypto/internal/hash.h> > > +#include <crypto/nhpoly1305.h> > > +#include <linux/crypto.h> > > +#include <linux/kernel.h> > > +#include <linux/module.h> > > + > > +#define NH_STRIDE(K0, K1, K2, K3) \ > > +({ \ > > + m_A = get_unaligned_le32(src); src += 4; \ > > + m_B = get_unaligned_le32(src); src += 4; \ > > + m_C = get_unaligned_le32(src); src += 4; \ > > + m_D = get_unaligned_le32(src); src += 4; \ > > + K3##_A = *key++; \ > > + K3##_B = *key++; \ > > + K3##_C = *key++; \ > > + K3##_D = *key++; \ > > + sum0 += (u64)(u32)(m_A + K0##_A) * (u32)(m_C + K0##_C); \ > > + sum1 += (u64)(u32)(m_A + K1##_A) * (u32)(m_C + K1##_C); \ > > + sum2 += (u64)(u32)(m_A + K2##_A) * (u32)(m_C + K2##_C); \ > > + sum3 += (u64)(u32)(m_A + K3##_A) * (u32)(m_C + K3##_C); \ > > + sum0 += (u64)(u32)(m_B + K0##_B) * (u32)(m_D + K0##_D); \ > > + sum1 += (u64)(u32)(m_B + K1##_B) * (u32)(m_D + K1##_D); \ > > + sum2 += (u64)(u32)(m_B + K2##_B) * (u32)(m_D + K2##_D); \ > > + sum3 += (u64)(u32)(m_B + K3##_B) * (u32)(m_D + K3##_D); \ > > +}) > > + > > +static void nh_generic(const u32 *key, const u8 *src, size_t srclen, > > + __le64 hash[NH_NUM_PASSES]) > > +{ > > + u64 sum0 = 0, sum1 = 0, sum2 = 0, sum3 = 0; > > + u32 k0_A = *key++; > > + u32 k0_B = *key++; > > + u32 k0_C = *key++; > > + u32 k0_D = *key++; > > + u32 k1_A = *key++; > > + u32 k1_B = *key++; > > + u32 k1_C = *key++; > > + u32 k1_D = *key++; > > + u32 k2_A = *key++; > > + u32 k2_B = *key++; > > + u32 k2_C = *key++; > > + u32 k2_D = *key++; > > + u32 k3_A, k3_B, k3_C, k3_D; > > + u32 m_A, m_B, m_C, m_D; > > + size_t n = srclen / NH_MESSAGE_UNIT; > > + > > + BUILD_BUG_ON(NH_PAIR_STRIDE != 2); > > + BUILD_BUG_ON(NH_NUM_PASSES != 4); > > + > > + while (n >= 4) { > > + NH_STRIDE(k0, k1, k2, k3); > > + NH_STRIDE(k1, k2, k3, k0); > > + NH_STRIDE(k2, k3, k0, k1); > > + NH_STRIDE(k3, k0, k1, k2); > > + n -= 4; > > + } > > + if (n) { > > + NH_STRIDE(k0, k1, k2, k3); > > + if (--n) { > > + NH_STRIDE(k1, k2, k3, k0); > > + if (--n) > > + NH_STRIDE(k2, k3, k0, k1); > > + } > > + } > > + > > This all looks a bit clunky to me, with the macro, the *key++s in the > initializers and these conditionals. > > Was it written in this particular way to get GCC to optimize it in the > right way? This does get compiled into something much faster than a naive version, which you can find commented out at https://github.com/google/adiantum/blob/master/benchmark/src/nh.c#L14. Though, I admit that I haven't put a ton of effort into this C implementation of NH yet. Right now it's actually somewhat of a translation of the NEON version. I'll do some experiments and see if it can be made into something less ugly without losing performance. > > > + hash[0] = cpu_to_le64(sum0); > > + hash[1] = cpu_to_le64(sum1); > > + hash[2] = cpu_to_le64(sum2); > > + hash[3] = cpu_to_le64(sum3); > > +} > > + > > +/* Pass the next NH hash value through Poly1305 */ > > +static void process_nh_hash_value(struct nhpoly1305_state *state, > > + const struct nhpoly1305_key *key) > > +{ > > + BUILD_BUG_ON(NH_HASH_BYTES % POLY1305_BLOCK_SIZE != 0); > > + > > + poly1305_core_blocks(&state->poly_state, &key->poly_key, state->nh_hash, > > + NH_HASH_BYTES / POLY1305_BLOCK_SIZE); > > +} > > + > > +/* > > + * Feed the next portion of the source data, as a whole number of 16-byte > > + * "NH message units", through NH and Poly1305. Each NH hash is taken over > > + * 1024 bytes, except possibly the final one which is taken over a multiple of > > + * 16 bytes up to 1024. Also, in the case where data is passed in misaligned > > + * chunks, we combine partial hashes; the end result is the same either way. > > + */ > > +static void nhpoly1305_units(struct nhpoly1305_state *state, > > + const struct nhpoly1305_key *key, > > + const u8 *src, unsigned int srclen, nh_t nh_fn) > > Since indirect calls are going out of style: can we get rid of the > function pointer? Or is the compiler already inferring that it always > refers to nh_generic()? > At least for now I want to use the same crypto_nhpoly1305_*_helper() functions for all nhpoly1305 implementations, and that requires that 'nh' be a function pointer. The helpers could be placed in a header and inlined which would turn 'nh' into a direct call, but it seemed to be too much code to inline, and normally 'nh' is only invoked once per 1024 bytes anyway. - Eric
![]() |