[Cfrg] comments requested on proposed hash-to-field changes in hash-to-curve draft

["Riad S. Wahby" <[e-mail]>]

Hello CFRG,

I'm writing to request feedback on some proposed changes to the
hash-to-curve draft that the hash-to-curve authors and others are
currently discussing. These changes regard the way that the input
octet-string is hashed into an element of the base field, which
is the first step in hashing to an elliptic curve.

We're discussing this issue and proposed changes on GitHub
    https://github.com/cfrg/draft-irtf-cfrg-hash-to-curve/issues/202
(but of course I'd be grateful for feedback via email, too).

As a brief overview of the issues we're trying to address:

The current function (called hash-to-base in draft-05) uses HKDF
to produce a pseudorandom byte string. This choice was motivated,
among other reasons, by our desire to have an indifferentiability
proof for Merkle-Damgaard hash functions and to allow for easy
domain separation.

Unfortunately, the current design suffers from three issues:

- Björn Haase points out that hashing is often expensive for smart
cards and embedded systems, which means that there's a strong
motivation to avoid HKDF and other HMAC-based constructions.

- Relatedly, several people have asked us to specify a way of using
functions from the SHA-3 family. There are no security issues with
using SHA-3 underneath HKDF/HMAC, but it's not necessary to do so.

- Leo Reyzin points out that, because of the way we use HKDF, we only
get domain separation from other uses of HKDF---*not* from other
uses of the hash function underlying HKDF. The result is that domain
separation "escapes" hash-to-curve in a rather unpleasant way.

The GitHub issue I referenced above proposes a simpler design that
attempts to address these issues. We would appreciate your feedback!

Regards,

-=rsw