Specify key derivation

[chris-wood]

The current spec punts on key derivation. In particular, it assumes some mechanism for deriving keys. To promote an EdDSA-like interface, wherein "private keys" are random seeds used to derive actual scalars, it would be useful to specify the key generation mechanism. This might look something like the following:

def DeriveKeyPair(seed, mode, suiteID, info):
  contextString = "VOPRF08-" || 
                  I2OSP(mode, 1) || I2OSP(suiteID, 2) ||
                  I2OSP(len(info), 2) || info
  skS = GG.HashToScalar(seed, DST = "DeriveKeyPair" || contextString)
  if skS == 0:
    raise DeriveKeyPairError
  pkS = ScalarBaseMult(skS)
  return skS, pkS

One could use this to derive keys for the OPRF, VOPRF, or POPRF protocol variants. For the POPRF case, info is repeated here and in the Evaluate interface, but this is not too dissimilar from HPKE, which admits application-specific information in the key schedule and at the AEAD level. Applications can choose how to expose info accordingly.

[armfazh]

(thinking out loud): when deriving keys based on the mode+info, we do this because it is expected to separate the key spaces, so --for example-- we ensure that generating keys for OPRF are likely not the same than those for VOPRF.

However, there is no way to determine whether a pair of keys (sk,pk) should be used in a particular protocol. In other words, any valid pair (sk,pk) can be used for any protocol variant. Is this something we need to prevent?

[chris-wood]

Is this something we need to prevent?

It's a good question, and something @tomrist and I discussed. There's (at least) two ways we can approach the question:

1. Assume applications are capable of generating keeping keys separate. That is, treat key generation or derivation as something external to the protocol.
2. Assume applications are incapable of keeping keys separate, and enforce key diversification within the protocol.

Option (2) is similar to EdDSA, which treats "private keys" as random seeds and then derives scalars and public group elements from those seeds within the signing APIs. An application that then reuses the same seed across protocol modes would be safe, as the underlying scalars used for evaluation would necessarily be different.

At the end of the day, this is a question of where the DeriveKeyPair should exist, and what's best for implementations. I think option (2) is a totally reasonable and safe approach to the problem. It does, however, have the tradeoff that the "abstraction" layer to the protocol shifts away from scalar and group elements and towards something based on byte strings (random byte strings as private keys, and random byte strings as public keys). That might actually be an improvement in the long term, as it leaks less of the underlying implementation details, namely, that a prime-order group is involved, to applications.

All that said, I think we should (a) specify key derivation and (b) do it within the protocol.

[daxpedda]

Related: #305.

I would like to note, that it is important for implementations to know what is supposed to be done in the case of DeriveKeyPairError. Is rejection sampling okay? Basically make a new seed and retry?

[bytemare]

However, there is no way to determine whether a pair of keys (sk,pk) should be used in a particular protocol. In other words, any valid pair (sk,pk) can be used for any protocol variant. Is this something we need to prevent?

Isn't VOPRF technically two protocols in one already? The evaluation part in VOPRF is in fact pure OPRF, and thus the same private key is used in OPRF and VOPRF. Given the proof work that has been done, is this a problem?

[chris-wood]

Given the proof work that has been done, is this a problem?

In general, we should strive to make sure that separate protocols use separate keys. The proposal above gets us this for essentially free.

[armfazh]

I support the idea of abstracting the pair of keys as opaque byte strings, and from them derive the required math objects.

So, a deterministic key generation method is then required. The term 'derivation', I think, it will no longer apply.