[CFRG] Re: BLAKE3 I-D

[Christopher Patton <[e-mail]>]

Hi all,

Before adopting BLAKE3, I think it would be useful to see how much of a
difference it would make in our applications. I would suggest looking
through RFCs published by CFRG and assess how performance would change if
they could have used BLAKE3. Off the top of my head:
- RFC 9180 - HPKE (replace HKDF?)
- draft-irtf-cfrg-opaque - OPAQUE
- RFC 9380 - hashing to elliptic curves

I'll add my own data point: draft-irtf-cfrg-vdaf. This draft specifies an
incremental distributed point function (IDPF), a type of function secret
sharing used in some MPC protocols. Most of the computation is spent on XOF
evaluation. For performance reasons, we try to use AES wherever we can in
order to get hardware support. We end up with a mix of TurboSHAKE128 and
AES, which is not ideal. It would be much nicer if we could afford to use a
dedicated XOF, but TurboSHAKE128 is not fast enough in software. I threw
together some benchmarks for B3:
https://github.com/cjpatton/libprio-rs/compare/main...cjpatton:libprio-rs:exp/blake3-for-idpf?expand=1

The results were interesting. Compared to Turbo, B3 is 30% faster, as
expected. Compared to the baseline (mix of Turbo and AES), B3 is 2-3x
slower for the client operation, as expected; but the server was slightly
faster, which frankly is a bit of a mystery. We'll need to dig into the
code more to be certain, as there may be some obvious inefficiencies on the
client side. But preliminarily, I would say B3 is probably too slow in
software for this application.

Chris P.