deriveKeyPair

Deterministically generate/derive a KeyPair using an existing private key and a seed as inputs. This operation is currently supported for ECDSA secp256r1 (NIST P-256), ECDSA secp256k1 and EdDSA ed25519.

Similarly to BIP32, the implemented algorithm uses an HMAC function based on SHA512 and it is actually an implementation of the HKDF rfc - Step 1: Extract function, which is practically a variation of the private-parent-key -> private-child-key hardened key generation of BIP32.

Unlike BIP32, where both private and public keys are extended to prevent deterministically generated child keys from depending solely on the key itself, current method uses normal elliptic curve keys without a chain-code and the generated key relies solely on the security of the private key.

Although without a chain-code we lose the aforementioned property of not depending solely on the key, it should be mentioned that the cryptographic strength of the HMAC depends upon the size of the secret key (see HMAC Security). Thus, as long as the master key is kept secret and has enough entropy (~256 bits for EC-schemes), the system is considered secure.

It is also a fact that if HMAC is used as PRF and/or MAC but not as checksum function, the function is still secure even if the underlying hash function is not collision resistant (e.g. if we used MD5). In practice, for our DKG purposes (thus PRF), a collision would not necessarily reveal the master HMAC key, because multiple inputs can produce the same hash output.

Also according to the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) rfc5869:

• a chain-code (aka the salt) is recommended, but not required.
• the salt can be public, but a hidden one provides stronger security guarantee.
• even a simple counter can work as a salt, but ideally it should be random.
• salt values should not be chosen by an attacker.

Regarding the last requirement, according to Krawczyk's HKDF scheme: While there is no need to keep the salt secret, it is assumed that salt values are independent of the input keying material (see Cryptographic Extraction and Key Derivation - The HKDF Scheme).

There are also protocols that require an authenticated nonce (e.g. when a DH derived key is used as a seed) and thus we need to make sure that nonces come from legitimate parties rather than selected by an attacker. Similarly, in DLT systems, proper handling is required if users should agree on a common value as a seed, e.g. a transaction's nonce or hash.

Moreover if a unique key per transaction is prerequisite, an attacker should never force a party to reuse a previously used key, due to privacy and forward secrecy reasons.

All in all, this algorithm can be used with a counter as seed, however it is suggested that the output does not solely depend on the key, i.e. a secret salt per user or a random nonce per transaction could serve this role. In case where a non-random seed policy is selected, such as the BIP32 counter logic, one needs to carefully keep state so that the same salt is used only once.

Parameters

Throws

Deterministically generate/derive a KeyPair using an existing private key and a seed as inputs. Use this method if the SignatureScheme of the private key input is not known.

Parameters

Throws