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

Change SHA-256 to SHA-512 for Ristretto255 #200

Closed bytemare closed 3 years ago

bytemare commented 3 years ago

Hello,

in https://github.com/cfrg/draft-irtf-cfrg-voprf/blob/72ad54bba21da719456d85d3a12304410f83448d/draft-irtf-cfrg-voprf.md#oprfristretto255-sha-256, it is specified to use SHA-256 with Ristretto255. SHA-256 outputs 32 bytes.

https://tools.ietf.org/html/draft-irtf-cfrg-ristretto255-decaf448-00#section-4.3.4 states that the one-way map operates on 64-byte strings.

The hash function to be used should be SHA-512, which outputs 64 bytes, as described in https://tools.ietf.org/html/draft-irtf-cfrg-hash-to-curve-10#appendix-B for the ristretto255_XMD:SHA-512_R255MAP_RO_ cipher suite.

chris-wood commented 3 years ago

expand_message_xmd requires that the hash function H "number of bits output ... MUST be b >= 2 * k", where k is the target security parameter. For ristretto255, k is 128, so SHA256 suffices here. We don't need a larger hash function.

jedisct1 commented 3 years ago

Even if this is not a curve, Ristretto255 not being part of the recommended suites in the hash-to-curve document is indeed going to be very confusing.

Even more since the only ristretto255 example in this very document is ristretto255_XMD:SHA-512_R255MAP_RO_.

chris-wood commented 3 years ago

@jedisct1 Are you suggesting we bump to SHA512? If so, why? (I understand that it doesn't match the example in hash-to-curve, so perhaps we should change that example to use SHA256.)

jedisct1 commented 3 years ago

ristretto255 is a natural extension for libraries implementing edwards25519, initially for the needs of Ed25519.

Using SHA512 allows sharing the same hash-to-field code for edwards25519 and ristretto255, and doesn't need to introduce another hash function, as SHA512 is already there, as a requirement for Ed25519.

chris-wood commented 3 years ago

Oh, that's a great point! @alxdavids, what do you think? Hearing no objections, I'll change this tomorrow.

bytemare commented 3 years ago

I agree with what @jedisct1 said. The natural candidate is SHA-512, and using this here would also contribute in greater consistency of general usage of Ristretto255.

chris-wood commented 3 years ago

Sold :-) Let's move to SHA-512.

chris-wood commented 3 years ago

The fix is in #203 -- please have a look!