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
