requirements and guidelines for alternative hash_to_base functions

[kwantam]

This patch gives guidance on how to define a new hash_to_base function and use it
in a way that won't interfere with existing suites.

closes #165

[kwantam]

We could add an appendix with a hash_to_base from cSHAKE-128 and/or cSHAKE-256,
but that might be overkill. Thoughts?

[JustinDrake]

that might be overkill. Thoughts?

Agreed :)

[chris-wood]

The latest changes LGTM!

[armfazh]

iiuc, ( something might be inaccurate in my description)

at a higher level, one can think that hash_to_base requires two functions: a hash function H1 and a pseudo-random function H2.

it would be better to give a description of hash_to_base in terms of H1, H2; and give criteria to choose H1 and H2. This is in some sense already included, but it might be clear for a reader having a notion that 2 functions are required.

Also, the ciphersuite can contain another field indicating this choice.

CURVE_ID ' -' HASH_ID '-' PRF_ID '-' MAP_ID '-' ENC_ID '-' 

Some examples:
P256-SHA256-HKDF-SSWU-RO
P256-SHA256-KMAC-SSWU-RO
P256-SHA3256-HKDF-SSWU-RO

As side comment: the ciphersuite string is starting to look as a C-struct or a configuration file rather than a unique identifier.

[kwantam]

at a higher level, one can think that hash_to_base requires two functions:
a hash function H1 and a pseudo-random function H2.

This would be a nice thought, but I don't think it's possible to generalize in the way you've stated without putting unnecessary restrictions on alternative hash-to-base functions. The reason is that in general it's not even true that hash_to_base requires H1 and H2!

As a few examples:

• How would you describe the current hash-to-base in terms of these two functions? We might be tempted to say that HKDF is H2 and (e.g.) SHA-256 is H1, but that doesn't work because there's no clean decomposition between HKDF and SHA-256---the former is built in terms of the latter.

• We might instead be tempted to say that H2 is somehow parameterized over H1, but that also doesn't work, because then what would H1 be when H2 = KMAC128? I don't see any sensible assignment to H1 in that case, because KMAC isn't parameterized over a hash function at all.

• What about the case where someone wants to use HMAC to combine msg, ctr, and DST, then somehow use the result as an AES key? But HMAC can't be H1 because it's not a hash, and AES can't be H2 because it's a PRG, not a PRF (using the distinction discussed above, from K10).

Backing up: the point of this section is not to try and teach someone how to make up their own hash_to_base function. The one we've got took a good bit of work to get to this point, and there are a lot of subtleties in designing a replacement. The point is to state the high-level requirements, and to show how to use it in a way that won't mess up security or interoperability for people using the hash_to_base function given in this document.

---

EDIT to add:

P256-SHA256-KMAC-SSWU-RO

Right, so this is an example of my second bullet above: KMAC doesn't work with SHA-256; it's not parameterized in terms of anything, it's built directly out of the Keccak sponge...

(This also means, admittedly, that the current example of KMAC128 in the HASH_ID field in Suites isn't perfect. I'm not convinced that matters so much there since it's only intended to illustrate how to construct the field, but I'll think about whether there's something better to be said. Fixed.)

[chris-wood]

I think @kwantam's comment above cleared this up, so I'm merging for now. @armfazh please file a separate issue if you think this section needs more work!