[CFRG] Re: BLAKE3 I-D

[Jean-Philippe Aumasson <[e-mail]>]

>From my recollection, I was a reviewer of HPKE and suggested that it
supports an arbitrary KDF (SHA3- or B3-based, for example) rather than the
specific, suboptimal HKDF construction; see
https://gist.github.com/veorq/76196fde31390a8696eac7e062c7b2ea.
(Made a similar argument a while ago for the Noise protocol and kinda
remember that HKDF was deemed more reliable and more "probably secure"; in
some other contexts HKDF is preferable as a default KDF because of its
direct FIPSness.)

Anyway, I'm not sure that the speed difference would be significant though,
as hash-like computation is dwarfed by that of pubkey ops in the protocols
you cite.

On Thu 15 Aug 2024 at 14:06 Christopher Patton <[e-mail]>
wrote:

> 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.
>
>
>
>
>