[zapps-wg] Hardware-accelerated verification of randomness beacon

[Jason Davies]

On 20 Apr 2018, at 14:08, Kobi Gurkan <kobi at qed-it.com> wrote:

> Out of interest - I'm not deeply familiar with Intel SHA extensions nor ARM
> NEON crypto - was wondering if you know of the top of your head if the
> abstraction is low level enough to compute only the compression function as
> well?

Yes; in fact, these intrinsics are lower-level than the compression function.
The code is pretty short, e.g. these 20 lines form the compression function on
ARM NEON:

  https://github.com/plutomonkey/verify-beacon/blob/db03392c510e501babf38992eff21826dc3d45eb/src/sha256.rs#L139-L159

In the case of iterated SHA-256, the input size is necessarily always smaller
than the block size after the first iteration, and so each iteration ends up
being just one call to the compression function after the first iteration.

One additional trick is that conversion to and from big-endian is unnecessary
between iterations.  A sufficiently smart compiler could of course figure this
out.

--
Jason Davies, https://www.jasondavies.com/