linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Biggers <ebiggers@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
	<linux-crypto@vger.kernel.org>,
	linux-fscrypt@vger.kernel.org,
	linux-arm-kernel <linux-arm-kernel@lists.infradead.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Paul Crowley <paulcrowley@google.com>,
	Greg Kaiser <gkaiser@google.com>,
	Michael Halcrow <mhalcrow@google.com>,
	"Jason A . Donenfeld" <Jason@zx2c4.com>,
	Samuel Neves <samuel.c.p.neves@gmail.com>,
	Tomer Ashur <tomer.ashur@esat.kuleuven.be>
Subject: Re: [RFC PATCH v2 09/12] crypto: nhpoly1305 - add NHPoly1305 support
Date: Fri, 19 Oct 2018 22:38:35 -0700	[thread overview]
Message-ID: <20181020053834.GC876@sol.localdomain> (raw)
In-Reply-To: <CAKv+Gu-5WM19g5HguDheAADbigKNxokDCFMekkt4OYdEEa8Avw@mail.gmail.com>

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@kernel.org> wrote:
> > From: Eric Biggers <ebiggers@google.com>
> >
> > 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@google.com>
> > ---
> >  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

  reply	other threads:[~2018-10-20  5:38 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-15 17:54 [RFC PATCH v2 00/12] crypto: Adiantum support Eric Biggers
2018-10-15 17:54 ` [RFC PATCH v2 01/12] crypto: chacha20-generic - add HChaCha20 library function Eric Biggers
2018-10-19 14:13   ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 02/12] crypto: chacha20-generic - add XChaCha20 support Eric Biggers
2018-10-19 14:24   ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 03/12] crypto: chacha20-generic - refactor to allow varying number of rounds Eric Biggers
2018-10-19 14:25   ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 04/12] crypto: chacha - add XChaCha12 support Eric Biggers
2018-10-19 14:34   ` Ard Biesheuvel
2018-10-19 18:28     ` Eric Biggers
2018-10-15 17:54 ` [RFC PATCH v2 05/12] crypto: arm/chacha20 - add XChaCha20 support Eric Biggers
2018-10-20  2:29   ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 06/12] crypto: arm/chacha20 - refactor to allow varying number of rounds Eric Biggers
2018-10-20  3:35   ` Ard Biesheuvel
2018-10-20  5:26     ` Eric Biggers
2018-10-15 17:54 ` [RFC PATCH v2 07/12] crypto: arm/chacha - add XChaCha12 support Eric Biggers
2018-10-20  3:36   ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 08/12] crypto: poly1305 - add Poly1305 core API Eric Biggers
2018-10-20  3:45   ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 09/12] crypto: nhpoly1305 - add NHPoly1305 support Eric Biggers
2018-10-20  4:00   ` Ard Biesheuvel
2018-10-20  5:38     ` Eric Biggers [this message]
2018-10-20 15:06       ` Ard Biesheuvel
2018-10-22 18:42         ` Eric Biggers
2018-10-22 22:25           ` Ard Biesheuvel
2018-10-22 22:40             ` Eric Biggers
2018-10-22 22:43               ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 10/12] crypto: arm/nhpoly1305 - add NEON-accelerated NHPoly1305 Eric Biggers
2018-10-20  4:12   ` Ard Biesheuvel
2018-10-20  5:51     ` Eric Biggers
2018-10-20 15:00       ` Ard Biesheuvel
2018-10-15 17:54 ` [RFC PATCH v2 11/12] crypto: adiantum - add Adiantum support Eric Biggers
2018-10-20  4:17   ` Ard Biesheuvel
2018-10-20  7:12     ` Eric Biggers
2018-10-23 10:40       ` Ard Biesheuvel
2018-10-24 22:06         ` Eric Biggers
2018-10-30  8:17           ` Herbert Xu
2018-10-15 17:54 ` [RFC PATCH v2 12/12] fscrypt: " Eric Biggers
2018-10-19 15:58 ` [RFC PATCH v2 00/12] crypto: " Jason A. Donenfeld
2018-10-19 18:19   ` Paul Crowley
2018-10-20  3:24     ` Ard Biesheuvel
2018-10-20  5:22       ` Eric Biggers
     [not found]     ` <2395454e-a0dc-408f-4138-9d15ab5f20b8@esat.kuleuven.be>
2018-10-22 11:20       ` Tomer Ashur
2018-10-19 19:04   ` Eric Biggers
2018-10-20 10:26     ` Milan Broz
2018-10-20 13:47       ` Jason A. Donenfeld
2018-11-16 21:52       ` Eric Biggers
2018-11-17 10:29         ` Milan Broz
2018-11-19 19:28           ` Eric Biggers
2018-11-19 20:05             ` Milan Broz
2018-11-19 20:30               ` Jason A. Donenfeld
2018-10-21 22:23     ` Eric Biggers
2018-10-21 22:51       ` Jason A. Donenfeld
2018-10-22 17:17         ` Paul Crowley

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=20181020053834.GC876@sol.localdomain \
    --to=ebiggers@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=gkaiser@google.com \
    --cc=herbert@gondor.apana.org.au \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-fscrypt@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhalcrow@google.com \
    --cc=paulcrowley@google.com \
    --cc=samuel.c.p.neves@gmail.com \
    --cc=tomer.ashur@esat.kuleuven.be \
    --subject='Re: [RFC PATCH v2 09/12] crypto: nhpoly1305 - add NHPoly1305 support' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).