Spell out the hash functions in each Method Name subsection

[csosto-pk]

2.5. Key Derivation

The derivation of encryption keys MUST be done from shared secret K
according to Section 7.2 in [RFC4253] with a modification on the
exchange hash H.

The PQ-hybrid key exchange hash H is the result of computing the
HASH, where HASH is the hash algorithm specified in the named PQ-
hybrid key exchange method name, over the concatenation of the
following

We could define the hash function in the PQ-hybrid abstraction and say all PQ-hybrid exchanges will use that hash. Or we could define the hash in the Method Name.

• We should spell out in the draft where the hash is defined.
• We also should consider the security level of the hash function for each method name. For example of the KEM is NIST Leve 3 we should probably go for SHA-384.

[csosto-pk]

Imo, the method name should define it, just in case there are newly discovers concerns with the hash and in order to align the KEM security levels with the hash security level.

[dstebila]

I'm not sure what you mean by defined in the "PQ-hybrid abstraction" -- do you mean that this document would specify that all PQ-hybrids use a specific hash function? That seems odd to me.

For other key exchange methods, RFC 4253 has the method name include the group name and the hash (e.g., diffie-hellman-group1-sha1), so it makes sense to me to have the hybrid key exchange method itself define the hash. In the group names used in OQS-OpenSSH, the hash is not explicitly stated, instead it's determined based on the level of the PQ algorithm, but I also would have no problems explicitly listing the hash in the method name.

[csosto-pk]

It was a thought we discussed with Torben about hardcoding the hash function in the 2.1 PQ-hybrid Key Exchange Method Abstraction section. Like saying that every time we do hybrid we will use hash XYZ. But I agree, that does not make much sense. We ought define the hash in the method name.

• We should spell out the hashes in the corresponding method names section in the draft. Currently we only mention it in section 2.5.
• We also should consider the security level of the hash function for each method name. For example of the KEM is NIST Leve 3 we should probably go for SHA-384.

[torben-hansen]

There is two things to consider:

• The hash algorithm
• The input to the hash algorithm

Assuming a common interface, we can define the input as an "abstract" thing that applies to all methods (it depends on the messages being send). The algorithm choice will be in the specification that instantiates the key exchange method.

My line of thought was a route similar to what the OPAQUE IETF follows: modular design where you plug in algorithms.

If we only have very few instantiations, that modularity might not make sense.

Thoughts?