Multi Party Key Management System (KMS) for Secp256k1 Elliptic curve based digital signatures.

Overview

Key Management System (KMS) for curve Secp256k1

Multi Party Key Management System (KMS) for Secp256k1 Elliptic curve based digital signatures.

Introduction

Digital Signature Algorithm (DSA) is the basic cryptographic primitive for blockchain interaction: private keys represent identities, transfer of ownership is done by means of signatures and the blockchain is maintained by miners verifying signatures using public keys. Moving the classical DSA constructions to threshold signature schemes can provide enhanced security by distributed key generation and distributed signing. The miners verification process stays the same such that the change is transparent to the blockchain operators and can be done at the wallet (KMS) level. Recent years have brought major breakthroughs for threshold and multi-signatures schemes providing practical multi-party schemes for common DSAs used in blockchain today, i.e. [1–4] for ECDSA, Schnorr and BLS.

We define two roles: Owner and Provider. The Owner is the end-user who owns the funds in the account and holds one secret share of the private key. The Provider is another share holder of the private key but has no funds tied to this private key. His role is to provide the additional security in the system aiding and enabling the owner to generate keys and transact in distributed fash- ion. From network perspective one Provider is connected to many Owners which together maintain the Provider, for example paying his cost in transaction fees. The Provider can run on any machine: from a Trusted Execution Environment (TEE) to machine operated by incentivized human operator. Multiple Providers can compete for Owners. To give concrete example for use case: a company employees are all Owners and a Server owned by the company is the Provider.

Currently supported features

Currently not supported

  • The library does not provide serialize and desrialize functionalities and not handling any form of network communication
  • The cryptography is not constant time or immune to side channel attacks
  • The library has no unified methodology to handle errors. Usually errors are propagated from lower level code.

To play with the code

It is best to start with the tests code:

  1. poc.rs for VE recovery and master keys generation
  2. ecdsa/two_party/test and schnorr/two_party/test for keygen, signing, rotation, hd tests. Notice that HD and rotation are commutative such that the order of the operations does not matter.

License

KMS is released under the terms of the GPL-3.0 license. See LICENSE for more information.

Development Process

The contribution workflow is described in CONTRIBUTING.md, in addition the Rust utilities wiki contains information on workflow and environment set-up.

Contact

For any questions, feel free to email us.

References

[1] R. Gennaro, S. Goldfeder. Fast Multiparty Threshold ECDSA with Fast Trustless Setup ACM Conference on Computer and Communications Security (CCS), 2018.

[2] Y. Lindell and A. Nof. Fast Secure Multiparty ECDSA with Practical Distributed Key Generation and Applications to Cryptocurrency Custody. ACM Conference on Computer and Communications Security (CCS), 2018.

[3] D. Boneh, M. Drijvers, G. Neven. Compact Multi-Signatures for Smaller Blockchains. Cryptology ePrint Archive, Report 2018/483. Last access Aug. 2018.

[4] G. Maxwell, A. Poelstra, Y. Seurin, P. Wuille. Simple Schnorr Multi-Signatures with Applications to Bitcoin. Cryptology ePrint Archive, Report 2018/068, Last accessed Aug. 2018.

Comments
  • linking with `link.exe` failed: exit code: 1181

    linking with `link.exe` failed: exit code: 1181

    I try to run ecdsa/two_Party/test.rs prompt error: linking with link.exe failed: exit code: 1181 note: LINK : fatal error LNK1181: cannot open input file 'gmp.lib'

    opened by vae520283995 6
  • HD Wallet - slight differences between ECDSA and Schnorr

    HD Wallet - slight differences between ECDSA and Schnorr

    Hi,

    I noticed the formula used to generate public key in HD Wallet for ECDSA and Schnorr is slightly different.

    In ECDSA, it is link to code let pub_key = pubkey * &f_l_fe;

    In Schnorr, it is link to code let pub_key = pubkey.clone() + &g * &f_l_fe;

    Is there some security issue hence the need to multiply the Schnorr public key with generator?

    Thanks!

    opened by briancrypto 2
  • Backward compatibility for chain_code

    Backward compatibility for chain_code

    Revert field chain_code to BigInt instead of Point (GE) for backward compatibility support.

    test chain_code::two_party::test::tests::test_chain_code ... ok
    test rotation::two_party::test::tests::test_coin_flip ... ok
    test schnorr::two_party::test::tests::test_get_child ... ok
    test schnorr::two_party::test::tests::test_flip_masters ... ok
    test schnorr::two_party::test::tests::test_key_gen ... ok
    test schnorr::two_party::test::tests::test_commutativity_rotate_get_child ... ok
    test ecdsa::two_party::test::tests::test_get_child ... ok
    test ecdsa::two_party::test::tests::test_flip_masters ... ok
    test schnorr::two_party::test::tests::test_recovery_scenarios ... ok
    test ecdsa::two_party::test::tests::test_recovery_scenarios ... ok
    test ecdsa::two_party::test::tests::test_commutativity_rotate_get_child ... ok
    
    opened by gbenattar 1
  • add paillier key rotation to ecdsa

    add paillier key rotation to ecdsa

    • party 1 generates a new Paillier key pair e2,d2
    • party 1 and party 2 run coin toss protocol and update private shares (already implemented)
    • party2 knows already c1 - encryption of x1 under the old Paillier public key e1, because of the homomorphism of Paillier encryption, party2 can compute by herself c2- the ciphertext of the updated party1 share.
    • party1 sends proof of equal encryption to party 2 : https://github.com/mortendahl/rust-paillier/issues/62
    • party2 verifies
    opened by omershlo 1
  • Update dependencies, Add salt to verifier API and bump version

    Update dependencies, Add salt to verifier API and bump version

    Please review https://github.com/ZenGo-X/kms-secp256k1/commit/9b4eb11774ba4ecc65e0cb10560aff69384bf9ef more carefully as it has design implications, in the prover we use Option<&[u8]> and default to SALT_STRING(and I don't think we have any explicit relationship between that option and the default) but in the verifier we require them to explicitly pass in the salt

    opened by elichai 0
  • Allow the user to define the library search path for gmp.lib

    Allow the user to define the library search path for gmp.lib

    This is related to https://github.com/ZenGo-X/kms-secp256k1/issues/25

    We want to make it easier to the https://github.com/nash-io/openlimits users to use the library without worrying about compiling gmp copying and copying it to the expected path.

    I just created a hacky build.rs to automatically copy the gmp.lib and gmp.dll files to the toolchain lib folder, but if the user doesn't want to use openlimits anymore and if the user forget about it, the user will leave both files in the folder.

    I just found a reasonable solution for it in this stackoverflow answer https://stackoverflow.com/a/32868075 and I would love to see it implemented here.

    opened by notdanilo 1
  • generate MasterKeys in poc.rs example code

    generate MasterKeys in poc.rs example code

    currently we just show keygen with schnorr and ecdsa. the complete the poc we must run also chain code generation once and generate Master Keys for schnorr and ecdsa using calls to set_master_key

    good first issue 
    opened by omershlo 0
  • implement serialize and deserialise

    implement serialize and deserialise

    The purpose of the code in KMS is to take a cryptographic protocol and to construct the actual messages that are supposed to be send among the participants.

    • In order.
    • without breaking the cryptography.
    • Minimizing the round trips as much as possible
    1. what is the best way to serialize / desialize in this case?
    2. take the output messages from each protocol (keygen, sign, rotate, chain code etc) and serialize them
    3. take the input messages from each protocol and deserialize them.
    help wanted question 
    opened by omershlo 0
Releases(v0.3.0)
Owner
[ZenGo X]
Threshold cryptography for blockchains. Projects with "city" in name are work in progress.
[ZenGo X]
Private key finder based on the (Bitcoin) secp256k1 elliptic curve.

keyripper keyripper is a powerful tool developed in Rust to assist in the recovery of Bitcoin private keys by leveraging the Baby-Step Giant-Step (BSG

Denzy 12 Sep 27, 2024
Rust implementation of multi-party Schnorr signatures over elliptic curves.

Multi Party Schnorr Signatures This library contains several Rust implementations of multi-signature Schnorr schemes. Generally speaking, these scheme

[ZenGo X] 148 Dec 15, 2022
Rust implementation of {t,n}-threshold ECDSA (elliptic curve digital signature algorithm).

Multi-party ECDSA This project is a Rust implementation of {t,n}-threshold ECDSA (elliptic curve digital signature algorithm). Threshold ECDSA include

[ZenGo X] 706 Jan 5, 2023
Two-party and multi-party ECDSA protocols based on class group with Rust

CG-MPC-ECDSA This project aims to implement two-party and multi-party ECDSA protocols based on class group with Rust. It currently includes schemes de

LatticeX Foundation 16 Mar 17, 2022
X25519 elliptic curve Diffie-Hellman key exchange in pure-Rust, using curve25519-dalek.

x25519-dalek A pure-Rust implementation of x25519 elliptic curve Diffie-Hellman key exchange, with curve operations provided by curve25519-dalek. This

dalek cryptography 252 Dec 26, 2022
L2 validity rollup combined with blind signatures over elliptic curves inside zkSNARK, to provide offchain anonymous voting with onchain binding execution on Ethereum

blind-ovote Blind-OVOTE is a L2 voting solution which combines the validity rollup ideas with blind signatures over elliptic curves inside zkSNARK, to

Aragon ZK Research 3 Nov 18, 2022
Flexible secp256k1 curve math library.

secp A flexible and secure secp256k1 elliptic curve math library, with constant-time support, and superb ergonomics. secp takes full advantage of Rust

null 7 Nov 1, 2023
Implementation of the BLS12-381 pairing-friendly elliptic curve group

bls12_381 This crate provides an implementation of the BLS12-381 pairing-friendly elliptic curve construction. This implementation has not been review

Zero-knowledge Cryptography in Rust 183 Dec 27, 2022
Elliptic curve cryptography on Soroban.

Elliptic Curve Cryptography on Soroban Contract examples and reusable primitives. Groth 16 verifier. This crate provides a SorobanGroth16Verifier obje

Xycloo Labs 5 Feb 10, 2023
ethers-rs signer using GCP KMS

ethers-gcp-kms-signer Installation Cargo cargo add ethers-gcp-kms-signer Usage Signer use ethers::prelude::*; use ethers_gcp_kms_signer::{GcpKeyRingRe

null 12 Apr 16, 2023
User-friendly secure computation engine based on secure multi-party computation

CipherCore If you have any questions, or, more generally, would like to discuss CipherCore, please join the Slack community. See a vastly extended ver

CipherMode Labs 356 Jan 5, 2023
Cryptle: a secure multi-party Wordle clone with Enarx

Cryptle: a secure multi-party Wordle clone with Enarx Wordle is a popular web-based game, where a single player has to guess a five-letter word in six

Nick Vidal 2 May 9, 2022
Keyhouse is a skeleton of general-purpose Key Management System written in Rust.

Keyhouse Keyhouse is a skeleton of general-purpose Key Management System. Keyhouse is not an off-the-shelf system, and it's not ready for production.

Bytedance Inc. 148 Jan 1, 2023
A pairing-based threshold cryptosystem for collaborative decryption and signatures used in HoneybadgerBFT implementation

threshold_crypto A pairing-based threshold cryptosystem for collaborative decryption and signatures. The threshold_crypto crate provides cryptographic

null 166 Dec 29, 2022
ZKP fork for rust-secp256k1, adds wrappers for range proofs, pedersen commitments, etc

rust-secp256k1 rust-secp256k1 is a wrapper around libsecp256k1, a C library by Peter Wuille for producing ECDSA signatures using the SECG curve secp25

null 53 Dec 19, 2022
stealth addresses library implementing ERC-5564 over secp256k1 in rust

eth-stealth-addresses rust library implementing ERC-5564 stealth addresses using canonical ECC over the secp256k1 curve. let's make privacy on evm cha

κασσάνδρα.eth 30 Oct 9, 2023
Bulletproofs and Bulletproofs+ Rust implementation for Aggregated Range Proofs over multiple elliptic curves

Bulletproofs This library implements Bulletproofs+ and Bulletproofs aggregated range proofs with multi-exponent verification. The library supports mul

[ZenGo X] 62 Dec 13, 2022
A suite of programs for Solana key management and security.

?? goki Goki is a suite of programs for Solana key management and security. It currently features: Goki Smart Wallet: A wallet loosely based on the Se

Goki Protocol 157 Dec 8, 2022
🧑‍✈ Version control and key management for Solana programs.

captain ??‍✈️ Version control and key management for Solana programs. Automatic versioning of program binaries based on Cargo Separation of deployer a

Saber 35 Mar 1, 2022