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

[Phillip Hallam-Baker <[e-mail]>]

Seems rather strange that we are discussing Threshold versions of exotic
cryptographic functions that we do not currently make use of in IETF
protocols at all when the group has still not been given the opportunity to
consider adopting the draft I proposed two years ago describing Threshold
Key Exchange and Threshold Key Generation.



On Wed, Nov 3, 2021 at 1:59 AM Hugo Krawczyk <[e-mail]> wrote:

> 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
>>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>