An Introduction to “White Paper 42” — Secret Value Distribution

Secret Value Distribution — the title for nChain’s “White Paper 42” — is a building block upon which many of nChain’s other public inventions are based on. In this article we will cover the technique and publish a simple golang gist using the go-bk library to allow you to play with it. Credit goes to nChain for the white paper — this article will simply summarize the content of the paper for a general audience.

The paper describes a method in which Alice and Bob can exchange information to generate a shared secret that acts as a master key from which an unbounded number of deterministic keys can be derived. The technique is an improved way of performing a Diffie-Hellman Key Exchange. A Diffie-Hellman Key Exchange is an innovative process by which two participants can exchange credentials to create a common shared secret between both participants.

The shared secret created in the WP42 method is an improvement upon the DH Key Exchange because of the ability to quickly derive new keys from the initial shared secret that is generated, and because the public nature of the blockchain ensures near-perfect security when generating the secret.

To generate the shared secret, each party agrees on a standard Elliptic Curve Cryptography System, such as secp256k1 as used in Bitcoin, to ensure a common generator point, G, is used. Alice then creates a master private key S_AM that is kept secret by herself. The corresponding public key P_AM is shared with Bob. Bob does the same, generating master private key S_BM and keeping it secret, and sharing the corresponding public key P_BM with Alice.

Alice then creates a message M and uses a standard algorithm (such as SHA256) to create a hash of the message resulting in a 256-bit integer. Alice then generates a new private key S_A1 where:

Where the addition that is performed is scalar addition between the two integers.

Since this initial private key is not a random number but is derived from Alice’s master key, the corresponding public key P_A1 is derivable from her master public key:

Thus, although Alice’s new private key is not known by Bob, he can derive her new public key as long as the message is shared.

Alice then signs the message M and sends this to Bob:

Since Bob now has a signature corresponding with Alice’s derived private key and the message, he can validate the signature against the calculated P_A1. Further checks can be performed against the message itself if required as well.

Now that Alice and Bob have each other’s derived public keys, they can each independently calculate the shared secret K as follows:

Because this shared secret is derived from the scalar multiplication of the two values, it is in the form of an elliptic curve point:

This can be converted into any standard key format using standard publicly known operations as agreed by both parties. Since x_k is a 256-bit integer, this alone can be used as a derived Bitcoin private key.

Note that once the shared secret K is calculated, Alice and Bob’s derived private keys can be discarded and never have to be stored. The shared secret can be discarded after a one time use or can be used as a master key from which further derived keys can be generated. We will cover those techniques in future articles.

The code below assumes Alice’s Private Key was derived per the steps taken above, and Bob’s Public Key was derived the same way.

// per WP042, generates a shared secret using Alice's private key and Bob's public key 
// shared secret can be x or y
import "github.com/libsv/go-bk/bec"
func SharedSecret(privKeyA *bec.PrivateKey, pubKeyB *bec.PublicKey) ([]byte, []byte) { 
    curve := bec.S256() 
    x, y := curve.ScalarMult(pubKeyB.X, pubKeyB.Y, privKeyA.D.Bytes())
    return x.Bytes(), y.Bytes()
}