Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Cryptographic keys need to be kept secret to preserve the secrecy of the encrypted data. For this reason, keys that are used to encrypt payment transactions (production keys) should not exist in whole out side an HSM (Hardware Security Module). If a key needs to be transferred from one HSM to another, It can be split into parts. Each part is then placed in a tamper evident package and shipped 


For spiting into 2 parts:

  1. tart with the Key (not 16 bytes):0123456789ABCDEFFEDCBA9876543210
  2. create a random number of the same length (16 bytes in this example): 53F3E87462D80A4FC9DD9F3F3149D989
  3. XOR the 2 numbers: 52D0AD13EB73C7A0370125A7471DEB99




The usual method of "splitting a key" K into two keys K0 and K1 given to two parties, for the purpose described, is as follows:

generate K1 randomly, of the same size as K;
set K0=K⊕K1K0=K⊕K1.
"Joining" K0K0 and K1K1 into KK is simply K=K0⊕K1K=K0⊕K1.

This construct is such that each of the two parties gain absolutely no advantage by getting its split key KjKj, unless it also gets the other; it just is random, and unrelated to KK.

This can be generalized to n>2n>2 parties that must all collaborate to reconstruct KK:

generate K1K1 to Kn−1Kn−1 randomly, of the same size as KK;
set K0=K⊕K1⊕..⊕Kn−1K0=K⊕K1⊕..⊕Kn−1.
Of course joining is K=K0⊕K1⊕..⊕Kn−1K=K0⊕K1⊕..⊕Kn−1.


The usual method of "splitting a key" KK into two keys K0K0 and K1K1 given to two parties, for the purpose described, is as follows:

  • generate K1K1 randomly, of the same size as KK;
  • set K0=KK1K0=K⊕K1.

"Joining" K0K0 and K1K1 into KK is simply K=K0K1K=K0⊕K1.

This construct is such that each of the two parties gain absolutely no advantage by getting its split key KjKj, unless it also gets the other; it just is random, and unrelated to KK.

This can be generalized to n>2n>2 parties that must all collaborate to reconstruct KK:

  • generate K1K1 to Kn1Kn−1 randomly, of the same size as KK;
  • set K0=KK1..Kn1K0=K⊕K1⊕..⊕Kn−1.

Of course joining is K=K0K1..Kn1K=K0⊕K1⊕..⊕Kn−1.

This can further be generalized to nn parties of which at least kk must collaborate to reconstruct KK, using Shamir secret sharing, or some other secret sharing scheme.

  • No labels