Re: [CFRG] Threshold OPRF support and draft-irtf-cfrg-voprf

[Hugo Krawczyk <[e-mail]>]

My preferred choices here are:

- Specify both: POPRF needs to be specified for the cases that need a
partial OPRF and 2HashDH needs to be specified for cases where 2HashDH is
sufficient, even without considering the threshold extension. Indeed,
2HashDH has advantages in terms of simplicity, 40 years of use (in the form
of blinding and different signature flavors), weaker cryptographic
assumptions, and an analysis in the Universally Composable framework. The
latter is used to prove the security of OPAQUE (and other applications);
namely, the analysis of OPAQUE formalizes Asymmetric PAKEs as UC objects
and the OPAQUE proof assumes the OPRF to satisfy a defined UC
functionality. POPRF does not currently have such formalization (I am not
saying it is impossible to have it, but that's the current situation). More
generally, I see no reason to use the more involved POPRF construction when
metadata values are not needed.

Btw,  2HashDH can also accommodate metadata values  by setting the 2HashDH
key to a regular PRF computed on the metadata value (e.g., we use that in
OPAQUE to address enumeration attacks). But, in general,  POPRF is better
as a partial OPRF, especially when verifiability  is needed.

- Specifying both with same or similar syntax would be my preferred way. I
would have assumed that doing so would be simple and natural but I guess
that I am missing something since otherwise the answer to this question
would be obvious.

- Specify both in the same document  the threshold variant as out of scope.

- The threshold variant can be defined in a separate document. Doing so
will take many months (or more) of work and we want to have a specification
of 2HashDH for use with OPAQUE and other applications for which 2HashDH
suffices (or where it is necessary, if you want to maintain the validity of
proofs).

Hugo

PS: I will be happy to discuss threshold applications in a separate thread
without derailing the discussion on the above  important questions.


On Tue, Nov 2, 2021 at 8:32 AM Christopher Wood <[e-mail]> wrote:

> As proposed during the CFRG meeting at IETF 111 [1], the latest version of
> draft-irtf-cfrg-voprf adopted the POPRF protocol from [2], which has the
> following syntax:
>
>    y = F(k, x, t)
>
> Where k is the server's private key, x is the client's private input, t is
> a public value agreed upon by client and server, and y is the PRF output.
> The motivation for this change was to enable applications and protocols
> that require "metadata" bound to the PRF output to scale beyond the "unique
> PRF key per metadata value" approach [3,4]. Moreover, with a fixed public
> value t, a POPRF is functionally equivalent to a classical OPRF.
>
> One question that arose subsequently to the release of [2] is the extent
> to which threshold secret sharing of a secret key k can be supported. The
> prior 2HashDH OPRF protocol can be easily deployed in a threshold manner,
> transparently to the client. In contrast, the 3HashSDHI POPRF protocol
> cannot. After discussion with others off-list, whether one can build a
> fast, pairing-free POPRF that supports thresholding seems an open research
> question.
>
> The current situation begs the following questions: Is thresholding a
> feature that is important for known use cases? What are these use cases?
> And, importantly, do folks want to use threshold systems to meet these use
> cases?
>
> [5] plainly laid out the case for thresholding, but whether the vision and
> demand has materialized is unclear to me. Understanding whether there are
> motivating use cases right now will help shape the ongoing specification
> work.
>
> In particular, assuming we want to support thresholding, we have the
> following questions:
>
> 1) Should we specify only the 2HashDH OPRF, 3HashSDHI POPRF, or both?
> 2) If both, should the syntax for the OPRF be kept separate from that of
> the POPRF? That is, should the document treat them as two separate
> cryptographic objects, each with their own API and ciphersuites?
> 3) If the 2HashDH OPRF is included, should we describe how to deploy the
> protocol in a threshold system? And if so, what do we say about distributed
> key generation?
>
> I think a reasonable outcome for the specification that would be maximally
> useful to implementers and protocol designers comes from the following
> answers:
>
> 1) Both, either in draft-irtf-cfrg-voprf or in separate documents.
> 2) Separate syntaxes.
> 3) Include threshold details but punt on the DKG protocol, similar to
> FROST [6].
>
> What do others think?
>
> Thanks,
> Chris
>
> [1]
> https://datatracker.ietf.org/meeting/111/materials/slides-111-cfrg-ietf111-cfrg-voprf-00.pdf
> [2] https://eprint.iacr.org/2021/864, but the order of x and t in the API
> are flipped
> [3]
> https://mailarchive.ietf.org/arch/msg/privacy-pass/QWtRvUQ4d3wS96rPzUYfKSfKWps/
> [4]
> https://mailarchive.ietf.org/arch/msg/privacy-pass/9THC0-P__-e90KycWLVJu7xDh68/
> [5]
> https://csrc.nist.gov/CSRC/media/Presentations/Threshold-Cryptography-Ready-for-Prime-Time/images-media/krawczyk-hugo-keynote-NTCW19.pdf
> [6]
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-frost-01#section-8
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>