decBRWHash: SIMD AXU Hash Family

• decBRWHash is an almost-XOR-universal hash family built on Bernstein–Rabin–Winograd polynomials that partitions messages into c substreams for SIMD processing.
• It reorganizes message blocks using a decimation strategy and recombines them through a Horner-style polynomial, achieving up to 23% speed-up compared to Poly1305.
• The hand-optimized AVX2 implementation leverages 5-limb arithmetic with delayed reductions to deliver efficient 4-way SIMD parallelism with negligible AXU overhead.

Searching arXiv for the primary paper and closely related BRWHash/polyHash references. decBRWHash is an almost-XOR-universal (AXU) hash family parameterised by a positive integer $c$ and built from Bernstein–Rabin–Winograd (BRW) polynomials over prime order fields. Its defining design choice is a decimation strategy that partitions message blocks into $c$ BRW substreams and then recombines them by a Horner-style polynomial in $x^d$. Choosing $c>1$ yields a hash function that can be implemented using $c$-way single instruction multiple data (SIMD) instructions. The reported implementations focus on $4\!-\decBRWHash$ in hand-optimised AVX2 assembly over the primes $2^{127}-1$ and $2^{130}-5$, with comparisons against polyHash and the widely deployed Poly1305; for $2^{130}-5$, the source reports that $4\!-\decBRWHash$ is faster than Poly1305 for messages of a few hundred bytes and reaches about $c$0 speed-up for message lengths in the few megabytes range (Nath et al., 9 Jul 2025).

1. Algebraic basis in BRW polynomials

The construction rests on two canonical ways to assemble field elements $c$1 into a polynomial: the usual Horner polynomial and the BRW polynomial. The Horner form is

$c$2

whereas the BRW polynomial is defined recursively by (Nath et al., 9 Jul 2025)

$c$3

The source attributes key algebraic properties of BRW polynomials to Bernstein, Sarkar, Nath–Sarkar, and Ghosh & Sarkar. Three properties are central. First, the map $c$4, $c$5, is injective. Second, for $c$6,

$c$7

with equality if and only if $c$8 is a power of two. Third, evaluation at a fixed $c$9 requires only

$x^d$0

In the implementation-oriented interpretation given in the source, the $x^d$1 ring multiplications are performed with delayed reductions and about $x^d$2 full reductions. This algebraic profile is the foundation for using BRW polynomials as a hashing primitive rather than the usual Horner chain.

2. Formal definition of $x^d$3

The family is instantiated over a prime $x^d$4 of the form $x^d$5, specifically $x^d$6 or $x^d$7 in the reported implementations. The bit-lengths $x^d$8, $x^d$9, and $c>1$0 of message blocks, key, and tag are chosen so that $c>1$1, $c>1$2, and $c>1$3. A binary message $c>1$4 of length $c>1$5 is split into $c>1$6-bit blocks $c>1$7 and padded as (Nath et al., 9 Jul 2025)

$c>1$8

where each $c>1$9 is an $c$0-bit field element and $c$1 is the length encoding.

With key $c$2, the hash family is defined by

$c$3

Its structure is based on $c$4 decimated BRW streams. Let

$c$5

pad $c$6, and for $c$7 define

$c$8

These $c$9 BRW outputs are then recombined using a Horner polynomial in $4\!-\decBRWHash$0. The parameter $4\!-\decBRWHash$1 is chosen as

$4\!-\decBRWHash$2

and

$4\!-\decBRWHash$3

Finally,

$4\!-\decBRWHash$4

A boundary case is explicit: when $4\!-\decBRWHash$5, $4\!-\decBRWHash$6 exactly. In that sense, decBRWHash is not a distinct algebraic family unrelated to BRWHash, but a parameterised extension that preserves the $4\!-\decBRWHash$7 instance.

3. Decimation and vectorised evaluation

The source describes vectorisation at two levels: the outer $4\!-\decBRWHash$8-way recombination and the inner BRW evaluation. For polyHash, the $4\!-\decBRWHash$9-way Horner step is described as standard: one groups blocks by residue modulo $2^{127}-1$0, forms $2^{127}-1$1 parallel Horner chains over $2^{127}-1$2, and finally collapses them. For decBRWHash, SIMD evaluation of four independent BRW polynomials over $2^{127}-1$3 is obtained by running the usual BRW recursion simultaneously on 4-tuples of blocks (Nath et al., 9 Jul 2025).

The AVX2-oriented representation uses four simultaneous field elements in $2^{127}-1$4-bit registers, with limbs in base $2^{127}-1$5. In the high-level algorithm, one first precomputes

$2^{127}-1$6

via 4-way SIMD squarings. The main BRW evaluation then proceeds with a stack-based recursion in which every scalar variable is replaced by a SIMD vector of length four. Each ring multiplication and reduction becomes a 4-way AVX2 field operation.

A key implementation detail is the use of unreducedBRW_t for fixed small $2^{127}-1$7, described as straight-line code evaluating a BRW of size $2^{127}-1$8 with delayed reductions. The stack discipline uses count-trailing-zeros(i) and pop-combine steps before multiplying by a factor of the form $2^{127}-1$9. This organisation makes the BRW recursion compatible with wide-lane SIMD execution without changing the underlying polynomial definition.

This suggests that decimation is not merely a data-layout device. It reorganises the message so that independent BRW instances align naturally with SIMD lanes, while the recombination polynomial $2^{130}-5$0 restores a single hash value.

4. Hand-optimised AVX2 realisation

For $2^{130}-5$1, the reported implementation uses a base-$2^{130}-5$2 5-limb representation,

$2^{130}-5$3

and packs four field elements $2^{130}-5$4 into five AVX2 registers $2^{130}-5$5, where $2^{130}-5$6 holds the $2^{130}-5$7-th limb of each of the four elements in its four 64-bit words (Nath et al., 9 Jul 2025).

The 4-way multiplication strategy forms all cross-products $2^{130}-5$8 using $2^{130}-5$9 vpmuludq instructions and accumulates them with vpaddq. The source notes that multiplications by $2^{130}-5$0 can be replaced by shifting plus addition if one side is pre-scaled. The unreduced result fits in $2^{130}-5$1 bits per limb.

Delayed reduction is an explicit optimisation. Up to $2^{130}-5$2 additions of unreduced products are accumulated before a full carry-chain reduction. Full reduction uses a 6-step chain of limb-by-limb carries and multiplies by $2^{130}-5$3, exploiting $2^{130}-5$4, and is implemented with a mix of vpand, vpsrlq, and vpsllq. The source also emphasises shuffle and register scheduling: $2^{130}-5$5, $2^{130}-5$6, and intermediate stack vectors are assigned to YMM registers so that no spills occur and dependency chains are broken, thereby recovering near-peak throughput for vpmuludq with latency $2^{130}-5$7 and throughput $2^{130}-5$8 per cycle, and for vpaddq with latency $2^{130}-5$9.

A further optimisation is the key-scaling trick. Whenever one operand of a multiplication is fixed, such as $4\!-\decBRWHash$0 or precomputed 5-scaled limbs, the five scaled limbs $4\!-\decBRWHash$1 are precomputed once so that each BRW step avoids “$4\!-\decBRWHash$2” multiplies. For $4\!-\decBRWHash$3, the same 5-limb AVX2 strategy is used, replacing $4\!-\decBRWHash$4 by $4\!-\decBRWHash$5 in reduction because $4\!-\decBRWHash$6. The authors also tried a 4-limb 32-bit representation for $4\!-\decBRWHash$7, but report that the extra unpack/add logic made it slower than the 5-limb code on current AVX2.

5. Empirical performance profile

The reported measurements were obtained on a single core of an Intel i7-1185G7 at $4\!-\decBRWHash$8 GHz, running Ubuntu 20.04, compiled with gcc 9.4 and flags -O3 -march=native, with cycle counts measured by RDPMC. The comparisons include Poly1305, an AVX2 implementation of $4\!-\decBRWHash$9 with delayed-reduction parameter $c$00, AVX2-$c$01 with BRW parameter $c$02, and a reference 64-bit “maax” code for $c$03 and $c$04 (Nath et al., 9 Jul 2025).

Representative cycle-per-byte results for key-powers computed on the fly are as follows.

Message length	Poly1305 / 4-decBRWHash	Speed-up
256 B	0.94 / 0.82	$c$05 (15%)
1 KB	0.70 / 0.55	$c$06 (27%)
4 KB	0.61 / 0.45	$c$07 (36%)
16 KB	0.43 / 0.34	$c$08 (26%)
1 MB	0.430 / 0.350	$c$09 (23%)

The source also states that, for $c$10, compared to the famous Poly1305 hash function, $c$11 is faster for messages a few hundred bytes long, achieves a speed-up of about $c$12 for message lengths in a few kilobytes range, and improves to about $c$13 for message lengths in a few megabytes range. More fine-grained tables for lengths $c$14 blocks of $c$15 bytes each, $c$16 blocks, and $c$17 blocks are reported in Tables 5–8 of the source. Across those experiments, $c$18 and $c$19 gave the best AVX2 performance. The same evaluation reports that beyond about $c$20 bytes AVX2-$c$21 outperforms the 64-bit maax code, and beyond about $c$22 KB AVX2-$c$23 outperforms its maax counterpart.

6. AXU security and the $c$24 trade-off

The security analysis uses a polynomial-degree argument. For any two distinct messages $c$25 of $c$26 blocks, the map

$c$27

is a nonzero polynomial of degree

$c$28

After reduction modulo $c$29 and then modulo $c$30, the failure chance is multiplied by $c$31, yielding the bound (Nath et al., 9 Jul 2025)

$c$32

Hence $c$33 is $c$34-AXU with

$c$35

The case $c$36 recovers the bound for standard $c$37. For $c$38, the degree and hence the bound grow by at most $c$39, which the source characterises as a negligible overhead for small $c$40. At the same time, $c$41 determines the SIMD width: doubling $c$42 doubles the parallelism but adds only $c$43 to the security bound and to the key storage, quantified in the source as approximately $c$44 bytes.

In practical terms, the reported implementation identifies $c$45 as a sweet spot on AVX2. This reflects the central design trade-off of decBRWHash: increasing $c$46 improves SIMD exposure while only mildly perturbing the AXU bound for small $c$47. The source therefore presents $c$48 as a drop-in AXU hash suitable for high-throughput SIMD-accelerated authentication and AEAD constructions.