Re: [Cfrg] Comments on draft-irtf-cfrg-vrf-01

[Sharon Goldberg <[e-mail]>]

Hi Marek,

Thank you for your review of draft-irtf-cfrg-vrf-01.  We addressed you
editorial comments in the new -02 version of the draft, posted today.  We
answer your questions below.

https://datatracker.ietf.org/doc/draft-irtf-cfrg-vrf/

>Moreover, the parameter description seems to require the size of the field
to be an even number of octets. This is, of course, not actually required,
as the instantiation with ED25519 in 5.5 shows. It should be explicitly
mentioned that 2n is the size of a field element in octets, rounded up.

Actually, in both curves we specify in the ciphersuites section, the prime
q is exactly 32 octets (in ED25519 it is 2^255-19). We could be more
general but that would add a potential point of confusion that is not
necessary for the current ciphersuites.

> Section 7.3 - It is possible to also consider deterministic nonce
generation, as in EdDSA.

We also felt this is a good idea. We modified the draft to allow for only
deterministic nonce generation, following either deterministic ECDSA (RFC
6979) or  EdDSA (RFC 8032)

> The matter of domain separation in the context of EC is suggested (in a
TODO) in 5.4. Perhaps it should be added to the RSA-based scheme as well. I
can't think of a specific reason, but this makes for a good practice.

We agree. We added domain separation for the ECVRF. If our approach is met
with general approval, we will do the same for the RSA VRF.

> General question:
> Does pi necessarily give alpha away? That is, in applications where alpha
needs to remain secret, does pi need to be kept secret as well? If not
necessarily, is this a property that the RFC guarantees, or maybe another
possible property for a specific scheme?

That is a good point. Indeed, pi does NOT hide alpha, and we explained this
in 7.5.

Thanks,
Sharon Goldberg + Leo Reyzin

On Mon, Mar 26, 2018 at 10:55 AM, Marek Jankowski <[e-mail]>
wrote:
>
> Dear Goldberg, Reyzin, Rapadopoulos and Vcelak,
> I have several comments and questions about the VRF RFC draft.
>
> Section 2 - The last sentence reads "... is correct VRF hash of ...", but
should be "... is the correct VRF hash of ...".
>
> Section 3.1 - The wording is somewhat confusing to me. specifically, the
second paragraph is a very formal security definition, while the following
one is much less formal, which makes this somewhat awkward to read. I
propose using the same style as section 3.2, which uses informal language
throughout the section (and in the second paragraph in particular).
> Additionally, the use of "More precisely" in the second paragraph of
section 3.2 should also be adopted , as it makes it a lot clearer that the
first paragraph is a general description of the two following ones.
>
> Section 5 - It would probably make for easier reading if, after
describing the security properties of EC-VRF, there was a reference to
section 5.6 for those needing full collision resistance and full uniqueness.
> Moreover, the parameter description seems to require the size of the
field to be an even number of octets. This is, of course, not actually
required, as the instantiation with ED25519 in 5.5 shows. It should be
explicitly mentioned that 2n is the size of a field element in octets,
rounded up.
>
> Section 5.4.1 - It feels worthwhile to explicitly note that the two
hash_to_curve implementations are not compatible. Perhaps explicit domain
separation should be added.
>
> Section 7.3 - It is possible to also consider deterministic nonce
generation, as in EdDSA.
>
> The matter of domain separation in the context of EC is suggested (in a
TODO) in 5.4. Perhaps it should be added to the RSA-based scheme as well. I
can't think of a specific reason, but this makes for a good practice.
>
> General question:
> Does pi necessarily give alpha away? That is, in applications where alpha
needs to remain secret, does pi need to be kept secret as well? If not
necessarily, is this a property that the RFC guarantees, or maybe another
possible property for a specific scheme?
>
> Thank you,
> Marek.
>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>



--
---
Sharon Goldberg
Computer Science, Boston University
http://www.cs.bu.edu/~goldbe