zengo-x / kms-secp256k1 Goto Github PK

• 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 : mortendahl/rust-paillier#62
• party2 verifies

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

specifically: for ecdsa key gen and for ecdsa sign.
an example on how to use Curv's ec-dh can be found in chain code

This is related to #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.

We need a specification of the protocol to better support binding tools, i.e., libs-core-bindings.

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

0. what is the best way to serialize / desialize in this case?
1. take the output messages from each protocol (keygen, sign, rotate, chain code etc) and serialize them
2. take the input messages from each protocol and deserialize them.

all key generation should call a function. same for rotation protocol

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!

this kms is specific for ecdsa. Its name should indicate it

@omershlo can you document?

When deriving child keys from master key 1 and master key 2,
the same code path should be used.

instead of directly calling the cryptographic libraries

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'