is it possible to generate set of child private keys from one parent private key, generated by ECC for example, securely? So that new private key (and derive public key) could be used for encryption or signing/verification?

The process of generation of a new private key could be relatively slow (up to a few seconds), so that even if attacker obtains some of the child private or derived public keys, he would not be able to derive parent private key - by lets say making some statistical analysis on them.

My intuitive take on this would be to basically encrypt the padded (deterministic)index of the child and then use some pwd hashing algorithm/technique like:

  • Key Stretching (bcrypt, scrypt, ...)
  • recursively calling HMAC multiple times

To obtain the child priv key. For the next child you should just increment the index. So in essence and without any other optimizations it could look like this:

function getChildPrivKey(index, parentPrivKey, parentHMACKey) {
  encryptedPaddedIndex = aes.encrypt(index, parentPrivKey)

  return recursivelyCallHMAC_X_Times(parentHMACKey, encryptedPaddedIndex, 'blake2b')

parentPrivateKey = ...
parentHMACKey = getRandomNumber()
firstChildIndex = 000....0 // 256x0

firstChildPrivateKey = getChildPrivKey(firstChildIndex, parentPrivateKey, firstChildIndex)
secondChildPrivateKey = getChildPrivKey(firstChildIndex+1 , parentPrivateKey, firstChildIndex)
// ...

My questions are:

  1. general: Is this a right direction?
  2. hmac: Would HMAC be considered convenient in this context over Key stretching with a salt (like in bcrypt or scrypt)?
  3. optimization: Would introducing many more recursive rounds of hashing make this better?

Thank you very much and I am sorry if this question is silly/trivial/mixing some concepts - I consider myself a relative newcomer to cryptography

  • 2
    $\begingroup$ Like the The twin diversity, and note that we don't use ECC for encryption, rather key exchange like x25519 and signatures like Ed25519. $\endgroup$ – kelalaka Jan 24 at 22:49
  • 2
    $\begingroup$ Just use HKDF. Or Blake3's derive_key mode. Or SHAKE as a KDF. Or any other KDF, so not bcrypt. $\endgroup$ – SAI Peregrinus Jan 24 at 22:52
  • 1
    $\begingroup$ If the master privatekey is secure, you don't need an artificially slow derivation; you do use that to 'strengthen' a password because a 'real' (human-chosen or human-known) password is NOT strong enough by itself. Bitcoin's 'hierarchical deterministic' derivation (for secp256k1 and ECDSA) uses single HMAC-SHA512, in a scheme that allows deriving privatekeys and if the 'nonhardened' option is used also deriving publickeys without the privatekey(s). $\endgroup$ – dave_thompson_085 Jan 25 at 3:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.