Re: [Cfrg] Static-DH oracles, strong-DH security

[Alex Davidson <[e-mail]>]

> On Fri, Nov 22, 2019 at 6:58 AM Filippo Valsorda <[e-mail]>
wrote:
> 2019-11-21 19:01 GMT-05:00 Taylor R Campbell <[e-mail]>:
> > To be clear: I don't mean to suppose limiting adversaries to 2^64
> > queries overall; rather, I mean to suppose limiting them to 2^64
> > queries made _one after the other_ -- not in parallel.
> >
> > What matters is the _latency_ of a query, not the _bandwidth_ of the
> > global Cloudflare network.  And I think it is quite reasonable to
> > suppose limiting the latency of a query to at least a nanosecond:
>
> I think it's even reasonable to assume a latency of 10 nanoseconds,
> meaning 684245902131068969 queries would take two centuries, leaving
> the only realistic attack at 2^118.

Thanks for both of your inputs. I agree that in the Internet setting
assuming this kind of latency on sequential queries is very likely not
to constrain any plausible adversary.

However, my contention is that the current draft-irtf-cfrg-vorpf
document describes a protocol in the generic sense, and the notion of
latency is not factored into the security model. This mirrors the
security model that the original (V)OPRF design [JKK14] uses, and so we
can invoke the proof of security that they provide for making arguments
about the security of the protocol.

The reason for describing the protocol in this manner is that it ensures
that the (V)OPRF is agnostic to the setting that it is used in. In turn,
this ensures that the security of the protocol is evaluated against the
*strongest* possible adversary. This also makes it possible to easily
evaluate the expected lower bound of the security parameter for a
(V)OPRF ciphersuite in any setting. This includes settings that the
adversary, for whatever reason, may enjoy 0ms latency per query.

As you point out, perhaps instantiating such an adversary is impossible
in the real world. However, in my opinion it is imperative that we make
*no* assumptions about the adversarial setting that the generic (V)OPRF
protocol is being used in, for the reasons above.

[JKK14]: https://eprint.iacr.org/2014/650.pdf