Sendover Key Derivation Scheme

Ty Everett ([e-mail])

Abstract

This technical standard proposes a key derivation method that allows two parties to derive multiple keys for each other in an open-ended manner. The method employs invoice numbers as a simple way for multiple keys to be derived. A sender can derive a public key for a recipient without knowing the recipient's corresponding private key, and the recipient can later use the sender's public key and the same invoice number to derive a corresponding private key. The proposed method removes the limit of 4 billion keys per child that is present in BIP321, improves the privacy of the involved parties by employing ECDH shared secrets, and enables an open-ended invoice numbering scheme for key derivation that can be further standardized for specific use-cases. The method can be used for private invoicing, digital signatures, symmetric cryptography, and other applications in Bitcoin and CBDC ecosystems.

Motivation

This technical standard is proposed to address the need for a standard method for key derivation between parties that enables greater ecosystem interoperability. While BIP321 provided a naive approach, it enabled only one key derivation universe per master public key. Conversely, this specification enables new key universes for every combination of two parties who interact, because the shared secret between their keys is employed. This also protects the privacy of the parties involved from outsiders who do not know the shared secret.

The proposed key derivation method offers several benefits. It enables two parties to derive many different keys for one another in an open-ended way, thereby providing greater flexibility. The use of invoice numbers as a simple way for multiple keys to be derived makes the method easy to use and enables further standardization. The method also employs ECDH shared secrets to improve privacy, and can be auditable by revealing shared secrets between specific counterparties to tax agencies for an audit to prove transactions. Additionally, higher-order protocol identifiers, key universes, and security levels within Bitcoin wallet and application architectures have been defined for this method.

Overall, this proposed key derivation method offers an improved approach to key derivation that can be used in various applications. It removes the limitations of existing key derivation methods such as BIP321 and provides greater flexibility, privacy, and auditability.

Specification

The key derivation is specified as follows:

Identity Keys

Each party has a master private key and a master public key that are derived from the secp256k1 elliptic curve.

Key Derivation

• The sender computes the shared secret by multiplying his master private key with the recipient's master public key using elliptic curve point multiplication.

• The sender uses the shared secret as the key to generate an HMAC over the invoice number.

• The HMAC is then converted into a scalar using big-endian encoding.

• The generator point G is multiplied by the scalar to generate a new point on the elliptic curve.

• The resulting point is added to the recipient's master public key point to produce a new point on the curve.

• The resulting point is then used to generate a new child public key.

• To derive the corresponding private key, the recipient computes the shared secret by multiplying his master private key with the sender's master public key using elliptic curve point multiplication.

• The recipient then generates the HMAC over the invoice number using the shared secret and computes the scalar in the same way as the sender.

• The scalar is then added to the recipient's master private key to generate the corresponding child private key.

Invoice Number

The invoice number is treated as a string and is converted into a buffer using UTF-8 encoding.

Steps for the Sender

1. The sender generates a shared secret by multiplying his master private key with the recipient's master public key using elliptic curve point multiplication.

2. The sender generates an HMAC over the invoice number using the shared secret as the key.

3. The HMAC is converted into a scalar using big-endian encoding.

4. The generator point G is multiplied by the scalar to generate a new point on the elliptic curve.

5. The resulting point is added to the recipient's master public key point to produce a new point on the curve.

6. The resulting point is then used to generate a new child public key for the given invoice number.

Steps for the Recipient

1. The recipient generates the shared secret by multiplying his master private key with the sender's master public key using elliptic curve point multiplication.

2. The recipient generates the HMAC over the invoice number using the shared secret as the key.

3. The HMAC is converted into a scalar using big-endian encoding.

4. The scalar is added to the recipient's master private key (mod N) to generate the corresponding child private key for the given invoice number.

Security Considerations

The security of this key derivation method relies on keeping the master private keys secure and the shared secret confidential. Any party with access to the shared secret could potentially derive the child keys as well, so it is important to keep the shared secret confidential. Private keys derived using this method should be treated with the same level of security as any other private key.

Conclusion

This specification provides a method for key derivation that enables two parties to derive many different keys for one another in an open-ended way. This method employs invoice numbers as a simple way for multiple keys to be derived and uses the secp256k1 elliptic curve for key derivation. The method is designed to be flexible and auditable, with potential applications including private invoicing,

Implementations

This specification has been implemented into the Sendover JavaScript library.

Test Vectors

Test vectors for this standard are provided:

For Testing Private Key Derivation

[
  {
    senderPublicKey: '033f9160df035156f1c48e75eae99914fa1a1546bec19781e8eddb900200bff9d1',
    recipientPrivateKey: '6a1751169c111b4667a6539ee1be6b7cd9f6e9c8fe011a5f2fe31e03a15e0ede',
    invoiceNumber: 'f3WCaUmnN9U=',
    privateKey: '761656715bbfa172f8f9f58f5af95d9d0dfd69014cfdcacc9a245a10ff8893ef'
  },
  {
    senderPublicKey: '027775fa43959548497eb510541ac34b01d5ee9ea768de74244a4a25f7b60fae8d',
    recipientPrivateKey: 'cab2500e206f31bc18a8af9d6f44f0b9a208c32d5cca2b22acfe9d1a213b2f36',
    invoiceNumber: '2Ska++APzEc=',
    privateKey: '09f2b48bd75f4da6429ac70b5dce863d5ed2b350b6f2119af5626914bdb7c276'
  },
  {
    senderPublicKey: '0338d2e0d12ba645578b0955026ee7554889ae4c530bd7a3b6f688233d763e169f',
    recipientPrivateKey: '7a66d0896f2c4c2c9ac55670c71a9bc1bdbdfb4e8786ee5137cea1d0a05b6f20',
    invoiceNumber: 'cN/yQ7+k7pg=',
    privateKey: '7114cd9afd1eade02f76703cc976c241246a2f26f5c4b7a3a0150ecc745da9f0'
  },
  {
    senderPublicKey: '02830212a32a47e68b98d477000bde08cb916f4d44ef49d47ccd4918d9aaabe9c8',
    recipientPrivateKey: '6e8c3da5f2fb0306a88d6bcd427cbfba0b9c7f4c930c43122a973d620ffa3036',
    invoiceNumber: 'm2/QAsmwaA4=',
    privateKey: 'f1d6fb05da1225feeddd1cf4100128afe09c3c1aadbffbd5c8bd10d329ef8f40'
  },
  {
    senderPublicKey: '03f20a7e71c4b276753969e8b7e8b67e2dbafc3958d66ecba98dedc60a6615336d',
    recipientPrivateKey: 'e9d174eff5708a0a41b32624f9b9cc97ef08f8931ed188ee58d5390cad2bf68e',
    invoiceNumber: 'jgpUIjWFlVQ=',
    privateKey: 'c5677c533f17c30f79a40744b18085632b262c0c13d87f3848c385f1389f79a6'
  }
]

For Testing Public Key Derivation

[
  {
    senderPrivateKey: '583755110a8c059de5cd81b8a04e1be884c46083ade3f779c1e022f6f89da94c',
    recipientPublicKey: '02c0c1e1a1f7d247827d1bcf399f0ef2deef7695c322fd91a01a91378f101b6ffc',
    invoiceNumber: 'IBioA4D/OaE=',
    publicKey: '03c1bf5baadee39721ae8c9882b3cf324f0bf3b9eb3fc1b8af8089ca7a7c2e669f'
  },
  {
    senderPrivateKey: '2c378b43d887d72200639890c11d79e8f22728d032a5733ba3d7be623d1bb118',
    recipientPublicKey: '039a9da906ecb8ced5c87971e9c2e7c921e66ad450fd4fc0a7d569fdb5bede8e0f',
    invoiceNumber: 'PWYuo9PDKvI=',
    publicKey: '0398cdf4b56a3b2e106224ff3be5253afd5b72de735d647831be51c713c9077848'
  },
  {
    senderPrivateKey: 'd5a5f70b373ce164998dff7ecd93260d7e80356d3d10abf928fb267f0a6c7be6',
    recipientPublicKey: '02745623f4e5de046b6ab59ce837efa1a959a8f28286ce9154a4781ec033b85029',
    invoiceNumber: 'X9pnS+bByrM=',
    publicKey: '0273eec9380c1a11c5a905e86c2d036e70cbefd8991d9a0cfca671f5e0bbea4a3c'
  },
  {
    senderPrivateKey: '46cd68165fd5d12d2d6519b02feb3f4d9c083109de1bfaa2b5c4836ba717523c',
    recipientPublicKey: '031e18bb0bbd3162b886007c55214c3c952bb2ae6c33dd06f57d891a60976003b1',
    invoiceNumber: '+ktmYRHv3uQ=',
    publicKey: '034c5c6bf2e52e8de8b2eb75883090ed7d1db234270907f1b0d1c2de1ddee5005d'
  },
  {
    senderPrivateKey: '7c98b8abd7967485cfb7437f9c56dd1e48ceb21a4085b8cdeb2a647f62012db4',
    recipientPublicKey: '03c8885f1e1ab4facd0f3272bb7a48b003d2e608e1619fb38b8be69336ab828f37',
    invoiceNumber: 'PPfDTTcl1ao=',
    publicKey: '03304b41cfa726096ffd9d8907fe0835f888869eda9653bca34eb7bcab870d3779'
  }
]

Acknowledgments

Credit is given to the people who have worked on making these ideas into reality. In particular, we thank Xiaohui Liu for creating the first known implementation of private addresses using this scheme, and Dr. Craig Wright for first describing it.

References

• 1: BIP32 Key Derivation Scheme