search

cfrg / draft-irtf-cfrg-voprf

Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups
https://cfrg.github.io/draft-irtf-cfrg-voprf/#go.draft-irtf-cfrg-voprf.html
Other
38 stars 15 forks source link

Ciphersuite section should cite standard curve generators and orders #142

Closed davidben closed 3 years ago

davidben commented 4 years ago

Section 4 defines various ciphersuites using standard curves, but it specifies the generator and order explicitly. The values are (modulo the issue below) always the standard one, as they should be. But from reading the draft you might not realize this and miss that you can reuse your existing base-point-specific optimizations. Instead, since curves are always specified and implemented with a standard base point, just cite the standard ones. No sense in restating the order either, I think.

This would also fix what appear to be mistakes in the curve25519 and curve448 definition:

First, a minor terminology nitpick: OPRF(curve25519, SHA-512) and OPRF(curve448, SHA-512) specify the base point with (x, y) coordinates, but RFC7748, which the draft cites, does not define the curves in terms of (x, y) coordinates at all. It labels the coordinates (u, v).

Second, the y/v-coordinate for the curve25519 generator is wrong. I don't know if it ends up mattering for VOPRF (I'm guessing not, since Serialize() only captures the x/u coordinate?), but there are two possible v-coordinates for u = 9. RFC7748, section 4.1 picks V(P) = 14781619447589544791020593568409986887264606134616475288964881837755586237401 = 0x20AE19A1B8A086B4E01EDD2C7748D14C923D4D7E6D7C61B229E9C5A27ECED3D9. This draft used p - V(P) = 0x5F51E65E475F794B1FE122D388B72EB36DC2B28192839E4DD6163A5D81312C14. (Edit: sounds like there's an errata in the RFC to switch to the other one.)

armfazh commented 4 years ago

The correct generator point for curve25519 is the one reported in the errata report. https://www.rfc-editor.org/errata/eid4730 So, the v (or y) coordinate is even.

davidben commented 4 years ago

Ah! The joys of immutable RFCs. :-(

chris-wood commented 3 years ago

We removed the generator from the appendix altogether, so I think this is now resolved. @davidben, please reopen if that's not the case!

davidben commented 3 years ago

Ah cool. And I see the curve25519 generator silliness is sidestepped with ristretto255. Although, a minor nitpick, I wonder if this went a step too far. Section 2.1 says to act on a prime-order group GG. Then ScalarBaseMult() is defined to be the "repeated application of the group operation on the base point". But I thought a plain prime-order group usually doesn't have a well-defined base point or generator. Perhaps some of the types want to be tweaked?

chris-wood commented 3 years ago

Yeah, every element is a generator, but ristretto255 pins one (the curve25519 base point):

Since ristretto255 is a prime-order group, every element except the identity is a generator, but for interoperability a canonical generator is selected, which can be internally represented by the Curve25519 basepoint, enabling reuse of existing precomputation for scalar multiplication. This is its encoding:

e2f2ae0a 6abc4e71 a884a961 c500515f 58e30b6a a582dd8d b6a65945 e08d2d76

davidben commented 3 years ago

Right, I'm saying that section 2.1 doesn't seem to talk about there being a base point. Probably we want to define GG as a group plus a particular generator. Or something else.

(The ristretto comment was about the confusion about which base point is correct for curve25519. Hopefully ristretto is specified correctly.)

chris-wood commented 3 years ago

Ah, gotcha. We can fix that.