---
title: 'decBRWHash: SIMD AXU Hash Family'
url: https://www.emergentmind.com/topics/decbrwhash
type: topic
---

# decBRWHash: SIMD AXU Hash Family

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 \(23\%\) speed-up for message lengths in the few megabytes range [2507.06490].

## 1. Algebraic basis in BRW polynomials

The construction rests on two canonical ways to assemble field elements \(M_1,\dots,M_\ell\in\F\) into a polynomial: the usual Horner polynomial and the BRW polynomial. The Horner form is
\[
\Poly(x;M_1,\dots,M_\ell)=
\begin{cases}
0,&\ell=0,\\
M_1x^{\ell-1}+M_2x^{\ell-2}+\cdots+M_{\ell-1}x+M_\ell,&\ell>0,
\end{cases}
\]
whereas the BRW polynomial is defined recursively by [2507.06490]
\[
\BRW(x;M_1,\dots,M_\ell)=
\begin{cases}
0,&\ell=0,\\
M_1,&\ell=1,\\
M_1x+M_2,&\ell=2,\\
(x+M_1)(x^2+M_2)+M_3,&\ell=3,\\
\BRW(x;M_1,\dots,M_{2^r-1})(x^{2^r}+M_{2^r})+\BRW(x;M_{2^r+1},\dots,M_\ell),&2^r\le \ell<2^{r+1},\ r\ge2.
\end{cases}
\]

The source attributes key algebraic properties of BRW polynomials to Bernstein, Sarkar, Nath–Sarkar, and Ghosh & Sarkar. Three properties are central. First, the map \(\F^\ell\to\F[x]\), \((M_1,\dots,M_\ell)\mapsto\BRW(x;M_i)\), is injective. Second, for \(\ell\ge3\),
\[
\deg\BRW(x;M_1,\dots,M_\ell)=2^{\lfloor\lg\ell\rfloor+1}-1\le 2\ell-1,
\]
with equality if and only if \(\ell\) is a power of two. Third, evaluation at a fixed \(\tau\in\F\) requires only
\[
\lfloor\ell/2\rfloor \text{ field multiplications,}\qquad \lfloor\lg\ell\rfloor \text{ squarings.}
\]

In the implementation-oriented interpretation given in the source, the \(\lfloor\ell/2\rfloor\) ring multiplications are performed with delayed reductions and about \(\lfloor\ell/2\rfloor/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 \(c\!-\decBRWHash\)

The family is instantiated over a prime \(p\) of the form \(2^m-\delta\), specifically \(p=2^{130}-5\) or \(p=2^{127}-1\) in the reported implementations. The bit-lengths \(n\), \(k\), and \(\mu\) of message blocks, key, and tag are chosen so that \(\mu<m\), \(k<m\), and \(\delta<2^\mu\). A binary message \(X\) of length \(L\) is split into \(n\)-bit blocks \((X_1,\dots,X_\ell)\) and padded as [2507.06490]
\[
\pad2(X_1,\dots,X_\ell)=\bigl(M_1,\dots,M_\ell,\bin_{m-1}(L)\bigr),
\]
where each \(M_i\) is an \((m-1)\)-bit field element and \(\bin_{m-1}(L)\) is the length encoding.

With key \(\tau\in\F_p\), the hash family is defined by
\[
c\!-\decBRWHash_\tau(X)=\Bigl(Q(\tau;M_1,\dots,M_\ell,\bin_{m-1}(L))\Bigr)\bmod p \;\bmod\,2^\mu.
\]
Its structure is based on \(c\) decimated BRW streams. Let
\[
\frakn=\lceil\ell/c\rceil,\qquad \frakm=c\frakn,
\]
pad \(M_{\ell+1}\dots M_\frakm=0\), and for \(i=1,\dots,c\) define
\[
Q_i(x)=\BRW\bigl(x;\;M_i,M_{i+c},M_{i+2c},\dots,M_{i+(\frakn-1)c}\bigr).
\]

These \(c\) BRW outputs are then recombined using a Horner polynomial in \(x^d\). The parameter \(d\) is chosen as
\[
d=
\begin{cases}
1,&X=\emptyset,\\
2^{\lfloor\lg\frakn\rfloor+1},&X\neq\emptyset,
\end{cases}
\]
and
\[
Q_{c+1}(x)=\Poly\bigl(x^d;Q_1(x),\dots,Q_c(x)\bigr)
=x^{(c-1)d}Q_1(x)+\cdots+Q_c(x).
\]
Finally,
\[
Q(x;M,\dots)=x\,\bigl(x\cdot Q_{c+1}(x)+\bin_{m-1}(L)\bigr).
\]

A boundary case is explicit: when \(c=1\), \(1\!-\decBRWHash=\BRWHash\) exactly. In that sense, decBRWHash is not a distinct algebraic family unrelated to BRWHash, but a parameterised extension that preserves the \(c=1\) instance.

## 3. Decimation and vectorised evaluation

The source describes vectorisation at two levels: the outer \(c\)-way recombination and the inner BRW evaluation. For polyHash, the \(c\)-way Horner step is described as standard: one groups blocks by residue modulo \(c\), forms \(c\) parallel Horner chains over \(\tau^c\), and finally collapses them. For decBRWHash, SIMD evaluation of four independent BRW polynomials over \(\tau\) is obtained by running the usual BRW recursion simultaneously on 4-tuples of blocks [2507.06490].

The AVX2-oriented representation uses four simultaneous field elements in \(5\times256\)-bit registers, with limbs in base \(2^{26}\). In the high-level algorithm, one first precomputes
\[
\tau,\tau^2,\tau^4,\dots,\tau^{2^{\lfloor\lg n\rfloor}}
\]
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 \(t\), described as straight-line code evaluating a BRW of size \(2^t-1\) with delayed reductions. The stack discipline uses `count-trailing-zeros(i)` and pop-combine steps before multiplying by a factor of the form \(\tau^{t+k}+\text{nextBlock}\). 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 \(Q_{c+1}\) restores a single hash value.

## 4. Hand-optimised AVX2 realisation

For \(p=2^{130}-5\), the reported implementation uses a base-\(2^{26}\) 5-limb representation,
\[
a=a_0+a_1\,2^{26}+\cdots+a_4\,2^{104},\qquad 0\le a_i<2^{26},
\]
and packs four field elements \((a^{(0)},a^{(1)},a^{(2)},a^{(3)})\) into five AVX2 registers \(U_0,\dots,U_4\), where \(U_j\) holds the \(j\)-th limb of each of the four elements in its four 64-bit words [2507.06490].

The 4-way multiplication strategy forms all cross-products \(a_{i,u}\times b_{i,v}\) using \(25\) `vpmuludq` instructions and accumulates them with `vpaddq`. The source notes that multiplications by \(5\) can be replaced by shifting plus addition if one side is pre-scaled. The unreduced result fits in \(57\) bits per limb.

Delayed reduction is an explicit optimisation. Up to \(64\) 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 \(5\), exploiting \(2^{130}\equiv5\), and is implemented with a mix of `vpand`, `vpsrlq`, and `vpsllq`. The source also emphasises shuffle and register scheduling: \(\tau^d\), \(\tau^{2^j}\), 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 \(5\) and throughput \(1\) per cycle, and for `vpaddq` with latency \(1\).

A further optimisation is the key-scaling trick. Whenever one operand of a multiplication is fixed, such as \(\tau^d\) or precomputed 5-scaled limbs, the five scaled limbs \((5M_1,\dots,5M_4)\) are precomputed once so that each BRW step avoids “\(\times5\)” multiplies. For \(p=2^{127}-1\), the same 5-limb AVX2 strategy is used, replacing \(5\) by \(1\) in reduction because \(2^{127}\equiv1\). The authors also tried a 4-limb 32-bit representation for \(2^{127}-1\), 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 \(3.0\) 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 \(\polyHash_{1305}\) with delayed-reduction parameter \(g\in\{1,2,3,4\}\), AVX2-\(4\!-\decBRWHash_{1305}\) with BRW parameter \(t\in\{2,3,4,5\}\), and a reference 64-bit “maax” code for \(\polyHash\) and \(\BRWHash\) [2507.06490].

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 | \(\times 1.15\) (15%) |
| 1 KB | 0.70 / 0.55 | \(\times 1.27\) (27%) |
| 4 KB | 0.61 / 0.45 | \(\times 1.36\) (36%) |
| 16 KB | 0.43 / 0.34 | \(\times 1.26\) (26%) |
| 1 MB | 0.430 / 0.350 | \(\times 1.23\) (23%) |

The source also states that, for \(2^{130}-5\), compared to the famous Poly1305 hash function, \(4\!-\decBRWHash\) is faster for messages a few hundred bytes long, achieves a speed-up of about \(16\%\) for message lengths in a few kilobytes range, and improves to about \(23\%\) for message lengths in a few megabytes range. More fine-grained tables for lengths \(1\ldots32\) blocks of \(16\) bytes each, \(50\ldots500\) blocks, and \(1\,000\ldots5\,000\) blocks are reported in Tables 5–8 of the source. Across those experiments, \(t=5\) and \(g=4\) gave the best AVX2 performance. The same evaluation reports that beyond about \(200\) bytes AVX2-\(\polyHash\) outperforms the 64-bit maax code, and beyond about \(1\) KB AVX2-\(4\!-\decBRWHash\) outperforms its maax counterpart.

## 6. AXU security and the \(c>1\) trade-off

The security analysis uses a polynomial-degree argument. For any two distinct messages \(X\ne X'\) of \(\ell\) blocks, the map
\[
\tau\mapsto Q(\tau;M(X))-Q(\tau;M(X'))
\]
is a nonzero polynomial of degree
\[
\deg Q < 2\ell+2c+1.
\]
After reduction modulo \(p\) and then modulo \(2^\mu\), the failure chance is multiplied by \(2^{m-k-\mu+1}\), yielding the bound [2507.06490]
\[
\Pr_\tau\bigl[\decBRWHash_\tau(X)\oplus\decBRWHash_\tau(X')=\alpha\bigr]
<
\bigl(2\ell+2c+1\bigr)\;2^{\,m-k-\mu+1}.
\]
Hence \(c\!-\decBRWHash\) is \(\epsilon\)-AXU with
\[
\epsilon=(2\ell+2c+1)\,2^{m-k-\mu+1}.
\]

The case \(c=1\) recovers the bound for standard \(\BRWHash\). For \(c>1\), the degree and hence the bound grow by at most \(2c+1\), which the source characterises as a negligible overhead for small \(c\). At the same time, \(c\) determines the SIMD width: doubling \(c\) doubles the parallelism but adds only \(O(1)\) to the security bound and to the key storage, quantified in the source as approximately \(160\times\lfloor\lg(\ell/c)\rfloor\) bytes.

In practical terms, the reported implementation identifies \(c=4\) as a sweet spot on AVX2. This reflects the central design trade-off of decBRWHash: increasing \(c\) improves SIMD exposure while only mildly perturbing the AXU bound for small \(c\). The source therefore presents \(4\!-\decBRWHash_{1305}\) as a drop-in AXU hash suitable for high-throughput SIMD-accelerated authentication and AEAD constructions.

Source: https://www.emergentmind.com/topics/decbrwhash