Guides
App Login

MPC Protocols

In order to use Builder Vault for signing or encryption, you need to enable the MPC protocol to be used in the MPC node configuration file.

ECDSA Signatures

In order to use ECDSA, you need to enable one of the following protocols.

DKLS23

DKLS23 is a state-of-the-art MPC protocol for computing ECDSA keys and signatures based on the research paper https://eprint.iacr.org/2023/765. The values below are used as default. So you only need to have [DKLS23.Features] in your config where you set to true the operations that you need, such as GenerateKey and Sign. 


[DKLS23]
  
  # Shortest allowed BIP-32 chain path.
  MinChainPathLength = 0
  
  # Cache size for intermediate public keys when using BIP-32 chain paths.
  Bip32CacheSize = 1024
  
  # Maximum number of presignatures that can be generated in one request.
  PresigGenRequestLimit = 100
  
  # Maximum number of presignatures that can be generated concurrently for the entire TSM node.
  PresigGenGlobalLimit = 5000
  
  # Whether to allow running the protocol with optimization, possible values are: inMemory, database.
  # Link: https://builder-vault-tsm.docs.blockdaemon.com/docs/mpc-protocols#dkls23
  DeactivatedPlayersCache = "inMemory"

# Controls which features of DKLS23 to enable. Each field corresponds to a method in the SDK.
[DKLS23.Features]
  GenerateKey = false
  GeneratePresignatures = false
  Sign = false
  SignWithPresignature = false
  GenerateRecoveryData = false
  PublicKey = false
  ChainCode = false
  Reshare = false
  CopyKey = false
  BackupKeyShare = false
  RestoreKeyShare = false
  ExportKeyShares = false
  ImportKeyShares = false
  BIP32GenerateSeed = false
  BIP32DeriveFromSeed = false
  BIP32DeriveFromKey = false
  BIP32ConvertKey = false
  BIP32ExportSeed = false
  BIP32ImportSeed = false
  BIP32Info = false

Upgrading from DKLS19 to DKLS23

If you already use the DKLS19 protocol, you can upgrade to the faster DKLS23 protocol. Note, however, that DKLS23 only works with recent versions of the SDK, so if you use older versions of the SDK, you may have to upgrade these as well. In addition, it's not possible to use DKLS23 with our legacy SDK (SDKv1).

You can upgrade from DKLS19 to DKLS23 with these steps:

  1. Change [DKLS19] to DKLS23 in the MPC node configuration files. You need to do thsi for all your MPC nodes. You will get an error if some MPC nodes are configured to use DKLS19 while others use DKLS23.
  2. Run a key reshare operation for each of your existing keys that were generated with DKLS19. This is not strictly required, but only after resharing will you get the benefits of DKLS23.
  3. Delete any existing presignatures that were generated with the DKLS19 protocol. These can no longer be used with DKLS23. If needed, you can generate new presignatures using the DKLS23 protocol.
  4. You can restore key share backups from DKLS19 after switching to the DKLS23 protocol. The exception is key share backups created with Builder Vault v48 or earlier. Calling RestoreBackup() with DKLS23 and these old key share backups will cause an error. In this case you should take new key share backups. If you really need to restore the old backups, you can do this with a Builder Vault instance configured to use DKLS19.

📘

Deprecation of DKLS19

DKLS19 is included in v70 LTS and will as such be supported until at least 2027-03-01. But it will not be part of future LTS versions.

Deactivated Players

Builder Vault applies a certain optimization to the DKLS23 protocol. As a consequence of this, a malicious MPC node may try to deviate from the correct protocol execution in a certain way. This will be detected by the current MPC node and does no harm, as long as the current node refuses to run too many signing operations with the other node. The node enforces this by adding the other node to a list called the DeactivatedPlayersCache as soon as the cheating is detected.

The MPC node will rarely need to deactivate other MPC nodes. This only happens if the other MPC node deliberately tries to cheat. In the rare cases where this occur, you need to consider the fact that you are under attack, and take appropriate action. If you at some point decide to continue operating with the other MPC node, you must first run a key reshare operation. The refreshment of key material has the effect that it is now safe to proceed with normal operation (signing, etc.). The key refreshment operation automatically clears the deactivated player cache.

The deactivated player cache normally lives in the memory of your MPC node. This means that if you use a setup with horizontal scaling, where your MPC node is replicated among several instances, a malicious node may be able to cause one signing session to abort on each instance . If the attacker can cause too many signing sessions for the same key to abort in this way, he may be able to extract information about the key. To prevent this, you must set DeactivatedPlayersCache = "database" if you have more than five instances of your MPC node running in a replicated setup. This causes the MPC node instances to maintain the list of deactivated players globally in the database, so as to prevent concurrent attempts at cheating form the same malicious player.

📘

Horizontal Scaling and DKLS23

Make sure to set DeactivatedPlayersCache = "database" if your setup involves more than five instances of the MPC node.

DKLS19

The DKLS19 protocol also computes ECDSA signatures. This protocol is based on the research paper https://eprint.iacr.org/2019/523. This protocol can produce signatures with any subset of t+1 or more MPC nodes. The protocol cannot be enabled together with SEPH18S or DKLS23. Since the DKLS23 protocol is superior in all aspects, the DKLS19 is only included for backwards compatibility. 

[DKLS19]
  
  # Shortest allowed BIP-32 chain path.
  MinChainPathLength = 0
  
  # Cache size for intermediate public keys when using BIP-32 chain paths.
  Bip32CacheSize = 1024
  
  # Maximum number of presignatures that can be generated in one request.
  PresigGenRequestLimit = 100
  
  # Maximum number of presignatures that can be generated concurrently for the entire TSM node.
  PresigGenGlobalLimit = 5000

# Controls which features of DKLS19 to enable. Each field corresponds to a method in the SDK.
[DKLS19.Features]
  GenerateKey = false
  GeneratePresignatures = false
  Sign = false
  SignWithPresignature = false
  GenerateRecoveryData = false
  PublicKey = false
  ChainCode = false
  Reshare = false
  CopyKey = false
  BackupKeyShare = false
  RestoreKeyShare = false
  ExportKeyShares = false
  ImportKeyShares = false
  BIP32GenerateSeed = false
  BIP32DeriveFromSeed = false
  BIP32DeriveFromKey = false
  BIP32ConvertKey = false
  BIP32ExportSeed = false
  BIP32ImportSeed = false
  BIP32Info = false

SEPH18S

As an alternative to DKLS19 and DKLS23, you can use SEPH18S which is based on the research paper https://eprint.iacr.org/2020/501. This protocol is faster in terms of bandwidth and latency, but contrary to DKLS19/DKLS23 it requires participation of 2t+1 MPC nodes when signing. This means that SEPH18S requires at least three MPC nodes to run.

# Computes ECDSA signatures. This protocol requires n >= 2t+1. Cannot be enabled together with DKLS19.
[SEPH18S]

  # Shortest allowed BIP-32 chain path.
  MinChainPathLength = 0

  # Cache size for intermediate public keys when using BIP-32 chain paths.
  Bip32CacheSize = 1024

  # Maximum number of presignatures that can be generated in one request.
  PresigGenRequestLimit = 1000
  
  # Maximum number of presignatures that can be generated concurrently for the entire TSM node.
  PresigGenGlobalLimit = 50000

[SEPH18S.Features]
  GenerateKey = false
  GeneratePresignatures = false
  Sign = false
  SignWithPresignature = false
  GenerateRecoveryData = false
  PublicKey = false
  ChainCode = false
  Reshare = false
  CopyKey = false
  BackupKeyShare = false
  RestoreKeyShare = false
  ExportKeyShares = false
  ImportKeyShares = false
  BIP32GenerateSeed = false
  BIP32DeriveFromSeed = false
  BIP32DeriveFromKey = false
  BIP32ConvertKey = false
  BIP32ExportSeed = false
  BIP32ImportSeed = false
  BIP32Info = false

Schnorr Signatures

To do Ed25519, Ed448, BIP340 or other Schnorr-based signatures, as used by Mina, Zilliqa, and Polkadot, you need to enable the SEPD19S MPC protocol:

# Computes Ed25519 and Ed448 signatures. This protocol only requires t < n.
[SEPD19S]

# Shortest allowed chain path. A chain path is used to derive many keys from a single master key.
  MinChainPathLength = 0
  
  # Maximum number of presignatures that can be generated in one request.
  PresigGenRequestLimit = 1000
  
  # Maximum number of presignatures that can be generated concurrently for the entire TSM node.
  PresigGenGlobalLimit = 100000

# Controls which features of SEPD19S to enable. Each field corresponds to a method in the SDK.
[SEPD19S.Features]
  GenerateKey = false
  GeneratePresignatures = false
  Sign = false
  SignWithPresignature = false
  GenerateRecoveryData = false
  PublicKey = false
  ChainCode = false
  Reshare = false
  CopyKey = false
  BackupKeyShare = false
  RestoreKeyShare = false
  ExportKeyShares = false
  ImportKeyShares = false

RSA

To enable RSA encryption and signing:

[ADN06]

# Controls which features of ADN06 to enable. Each field corresponds to a method in the SDK.
[ADN06.Features]
  PublicKey = false
  SignPKCS1v15 = false
  SignPSS = false
  Decrypt = false
  ExportKeyShares = false
  ImportKeyShares = false

ECDH

The SEPD20ECDSA protocol is an MPC protocol that computes the ECDH function. This protocol can operate with any t+1 of the MPC nodes.

# Controls which features of SEPD20ECDH to enable. Each field corresponds to a method in the SDK.
[SEPD20ECDH.Features]
  GenerateKey = false
  ComputeSecret = false
  PublicKey = false

AES and HMAC

To use Builder Vault for the various AES operations (AES-GCM, AES-CBC, etc.) as well as HMAC, you will need to enable one of the following general purpose MPC protocols.

You also need to enable a general purpose MPC protocol to use the AN10922 and RFC5649 operations. These operations, however, are currently only available via our legacy SDK.

MRZ15

The MRZ15 protocol is a general-purpose MPC protocol that works for three players and security threshold t = 1, based on the research paper https://eprint.iacr.org/2015/931. It is relatively fast, but it requires all three MPC nodes to participate in the operation.

# Controls which AES features are enabled for MRZ15. Each field corresponds to a method in the SDK.
[MRZ15.AESFeatures]
  GenerateKey = false
  ExportKeyShares = false
  ImportKeyShares = false
  CTRKeyStream = false
  CBCEncrypt = false
  CBCDecrypt = false
  GCMEncrypt = false
  GCMDecrypt = false
  CMAC = false

# Controls which HMAC features are enabled for MRZ15. Each field corresponds to a method in the SDK.
[MRZ15.HMACFeatures]
  GenerateKey = false
  ExportKeyShares = false
  ImportKeyShares = false
  HMACSHA256 = false
  HMACSHA512 = false

# Controls which AN10922 features are enabled for MRZ15. Each field corresponds to a method in the SDK.
[MRZ15.AN10922Features]
  ImportKeyShares = false
  DeriveAESKey = false
  Checksum = false

# Controls which RFC5649 features are enabled for MRZ15. Each field corresponds to a method in the SDK.
[MRZ15.RFC5649Features]
  ImportKeyShares = false
  AesWrapBlobWithPadding = false

WRK17

WRK17 is another general purpose MPC protocol. It works for two MPC nodes and is based on the research paper https://eprint.iacr.org/2017/189.

[WRK17]
  KeySize = 16
  Rho = 40
  BucketSize = 4

# Controls which AES features are enabled for WRK17. Each field corresponds to a method in the SDK.
[WRK17.AESFeatures]
  GenerateKey = false
  ExportKeyShares = false
  ImportKeyShares = false
  CTRKeyStream = false
  CBCEncrypt = false
  CBCDecrypt = false
  GCMEncrypt = false
  GCMDecrypt = false
  CMAC = false

# Controls which HMAC features are enabled for WRK17. Each field corresponds to a method in the SDK.
[WRK17.HMACFeatures]
  GenerateKey = false
  ExportKeyShares = false
  ImportKeyShares = false
  HMACSHA256 = false
  HMACSHA512 = false

# Controls which AN10922 features are enabled for WRK17. Each field corresponds to a method in the SDK.
[WRK17.AN10922Features]
  ImportKeyShares = false
  DeriveAESKey = false
  Checksum = false

Broadcast

In some cases it is handy to use Builder Vault as a way to broadcast arbitrary messages to all the MPC nodes.

[BROADCAST]
  
  # Maximum size in bytes for a broadcast message.
  MaxMessageLength = 65536

# Controls which features of BROADCAST to enable. Each field corresponds to a method in the SDK.
[BROADCAST.Features]
  SimpleBroadcast = false
  AdvancedBroadcast = false

Updated about 2 months ago