Merge the changes of H2C into stable

[iquerejeta]

Would you consider including the H2C functions in the stable branch? Happy to create a PR if you'd accept it.

[jedisct1]

-stable gets performance and portability improvements, but the API remains the same. This is to avoid bindings that work with some 1.0.18-stable versions but won't with others.

H2C is actually a major blocker for releasing a new point version. The specification has been a bit of a moving target, and is not finalized yet.

Protocols also use it in an inconsistent way. In spite of the cipher suites only SHA-512 for XMD with edwards25519, other drafts use it with SHA-256. A last minute hack was made to the libsodium API to allow users to pick the hash function, but this is not great and may be reverted.

hash_to_ristretto255 not being a H2C suite is also annoying. No specified hash function, no test vectors.

So, until the H2C specification and the way it's used stabilizes, the plan is rather to eventually tag a new libsodium point release without H2C, and bring the code back later.

[iquerejeta]

I see, yes, this makes sense. Let's hope that it stabilises soon then 👍

[chris-wood]

@jedisct1 in case it helps, H2C is now past the point where technical changes will be made. Any updates from here on out will be strictly editorial.

[jedisct1]

I also remember protocols requiring the hash-to-field operation, so we need to make a public API for it as well. The current one is private and specialized.

[jedisct1]

The VOPRF draft is an example requiring the hash-to-field operation.

[iquerejeta]

I would be happy to dedicate a few cycles to this whenever it is decided to go forward 👍