HKDF in place of ad-hoc PRG currently used by hash_to_base?

[kwantam]

Dan Boneh points out that there's little reason to roll our own PRG inside hash_to_base. Instead, he suggests using HKDF.

(I have to admit, I'm slightly annoyed at myself for having failed to consider this option. Sorry, folks.)

While this makes hash_to_base slightly more expensive, the difference in cost is negligible compared to the end-to-end cost of hashing to a curve.

The main issues I see with taking this approach are:

• is there a way to get "prehash for free" as in the current approach?
• is there a compatibility story for the BLS signatures standard?

@hoeteck, thoughts on how this might play out with BLS? I can imagine there isn't a huge appetite for this change. On the other hand, I wonder if we can really justify using a hash_to_base function that lacks rigorous analysis when the (arguably) "right thing" is kind of well known?

[hoeteck]

Using HKDF is a great idea, indeed! It's also used in TLS 1.3.

HKDF-Expand also takes as input a context/info, and ciphersuite/domain separation info would fit in naturally over there.

thoughts on how this might play out with BLS?

Come to think about it, we should probably use HKDF for key generation in BLS signatures, since it also takes into account weak randomness used for key generation.

I have to admit, I'm slightly annoyed at myself for having failed to consider this option.

You're doing great! Don't be so harsh on yourself :)

[chris-wood]

Using HKDF is a great idea, indeed! It's also used in TLS 1.3.

+1!

You're doing great! Don't be so harsh on yourself :)

Heavy +1.

[kwantam]

Closed by #141