Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix clippy warnings and format README #71

Merged
merged 37 commits into from
Nov 3, 2019

Conversation

kigawas
Copy link
Contributor

@kigawas kigawas commented Aug 15, 2019

Fix #72
Fix #74

@kigawas
Copy link
Contributor Author

kigawas commented Aug 15, 2019

Readme was formatted by https://github.com/DavidAnson/vscode-markdownlint

@kigawas kigawas changed the title Fix key_gen.rs clippy warnings and format README Fix clippy warnings and format README Aug 15, 2019
@kigawas kigawas changed the title Fix clippy warnings and format README Fix clippy warnings and format README in bench Aug 15, 2019
@kigawas kigawas changed the title Fix clippy warnings and format README in bench Fix clippy warnings and format README Aug 15, 2019
@omershlo omershlo self-requested a review August 15, 2019 05:17
@omershlo omershlo self-assigned this Aug 15, 2019
@omershlo
Copy link
Contributor

hi @kigawas -
in my audit1 branch I also fixed clippy warnings a couple of days ago (its an audit branch and clippy is part of the audit). I do see that you have some good fixes in this PR as well as the new readme, but I am not sure how to merge them in my branch. Can you help please?

As a side comment we are working on adding tags which will make life easier for all.

@kigawas
Copy link
Contributor Author

kigawas commented Aug 15, 2019

We can merge this PR first and resolve conflicts later

README.md Outdated Show resolved Hide resolved
@omershlo
Copy link
Contributor

@oleiba

@omershlo omershlo closed this Aug 15, 2019
@omershlo omershlo reopened this Aug 15, 2019
@kigawas
Copy link
Contributor Author

kigawas commented Aug 16, 2019

moved some dependencies to dev-dependencies, mainly rocket

@kigawas
Copy link
Contributor Author

kigawas commented Sep 22, 2019

For 1, mainly in this commit
8a7d1a5

Rational:
Only deriving ParitialEq for part of messages is not consistent, actually, the comparing equal part should be left to user. Like this

use multi_party_ecdsa::protocols::multi_party_ecdsa::gg_2018::party_i::{
	KeyGenBroadcastMessage1 as KeyGenCommit, KeyGenDecommitMessage1 as KeyGenDecommit,
};
use curv::cryptographic_primitives::proofs::sigma_dlog::DLogProof;
use curv::cryptographic_primitives::secret_sharing::feldman_vss::VerifiableSS;
use curv::FE;

#[derive(Clone, Debug, Serialize, Deserialize)]
pub enum KeyGenMessage {
	CommitAndDecommit(PeerIndex, KeyGenCommit, KeyGenDecommit),
	VSS(PeerIndex, VerifiableSS),
	SecretShare(PeerIndex, FE),
	Proof(PeerIndex, DLogProof),
}

impl PartialEq for KeyGenMessage {
	fn eq(&self, other: &Self) -> bool {
		match (self, other) {
			(Self::CommitAndDecommit(ia, ca, da), Self::CommitAndDecommit(ib, cb, db)) => {
				ia == ib
					&& ca.com == cb.com && ca.e == cb.e
					&& da.blind_factor == db.blind_factor
					&& da.y_i == db.y_i
			}
			(Self::VSS(ia, vssa), Self::VSS(ib, vssb)) => ia == ib && vssa == vssb,
			(Self::SecretShare(ia, ssa), Self::SecretShare(ib, ssb)) => ia == ib && ssa == ssb,
			(Self::Proof(ia, pa), Self::Proof(ib, pb)) => ia == ib && pa == pb,
			_ => false,
		}
	}
}

@kigawas
Copy link
Contributor Author

kigawas commented Sep 22, 2019

For 2, I only remove the redundant mod like

// test.rs
#[cfg(test)]
mod tests {  // <- no need
    fn test_a() {}
    fn test_b() {}
}
// lib.rs
mod test;

to

// test.rs
fn test_a() {}
fn test_b() {}
// lib.rs
#[cfg(test)]
mod test;

@kigawas
Copy link
Contributor Author

kigawas commented Sep 22, 2019

This should also be applied to bench

@kigawas
Copy link
Contributor Author

kigawas commented Sep 22, 2019

Also add test of checking signature against other secp256k1 library (https://github.com/sorpaas/libsecp256k1-rs)

cce7832

@omershlo
Copy link
Contributor

omershlo commented Sep 22, 2019

some examples for new variables:
raw_msg
raw_pk
compact

I don't understand why they are necessary ?

2)I think that It is impossible to implement PatrtialEq from outside the library if some elements in the struct are private. Usually when there's a PartialEq derive it means that it is was required by some other library. Therefore I am not very excited with removing them for now

@kigawas
Copy link
Contributor Author

kigawas commented Sep 22, 2019

If you add more variables, you have to add new names

Simply deriving PartialEq is not enough, user has to adapt it to his own needs, which means that comparing two messages are equal or what makes them equal should be left to user's implementation. It's certainly possible, the example above was copied from real codes I'm writing.

And if you define "messages", obviously they are used outside, and their fields should be public.

@kigawas
Copy link
Contributor Author

kigawas commented Sep 22, 2019

Of course, deriving PartialEq for all messages is also a solution, which makes user write less codes.

I have no preference for this though, both of them are okay

Cargo.toml Show resolved Hide resolved
Cargo.toml Show resolved Hide resolved
Cargo.toml Outdated
serde_json = "1.0"
libsecp256k1 = "0.2.2"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this dependency needed?
I don't see it consumed anywhere.
Also curv uses secp256k1 and not libsecp256k1 and for a very good reason I believe - secp256k1 uses C bindings for libsecp256k1 in C, which is by far the most battle tested library for secp256k1...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is for testing signature against another secp256k1 repo

Rust wrapper of C bindings for libsecp256k1 is not reliable as you think, see rust-bitcoin/rust-secp256k1#163

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Of course, I'm just saying the rust wrapper is with problem

Copy link
Contributor

@oleiba oleiba Sep 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please point me to where libsecp256k1 is consumed?

Copy link
Contributor Author

@kigawas kigawas Sep 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

libp2p and substrate, is it enough to convince you?
https://github.com/libp2p/rust-libp2p
https://github.com/paritytech/substrate/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even it is not widely used, there is no hurt if you use it for testing against signature

Copy link
Contributor Author

@kigawas kigawas Sep 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And why we don't use C bindings?
The answer is:
rust-bitcoin/rust-secp256k1#163

That is to say, it'll break the test

let party_keys_vec = (0..n.clone())
.map(|i| Keys::create(i))
.collect::<Vec<Keys>>();
let (t, n) = (t as usize, n as usize);
Copy link
Contributor

@oleiba oleiba Sep 22, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is just a handy redefinition to avoid lots of as usize below

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it doesn't fix #72?

Copy link
Contributor Author

@kigawas kigawas Sep 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should've already fixed

Copy link
Contributor Author

@kigawas kigawas Sep 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

image

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll also fix other usize

Copy link
Contributor Author

@kigawas kigawas Sep 23, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

About party_index, since secret shares (in curv) are taking usize, I'll just keep it here

Copy link
Contributor

@oleiba oleiba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for your work. I added comments I'll be glad to discuss.

@omershlo
Copy link
Contributor

@kigawas is it possible to divide this PR into few smaller PRs?
I think it will be easier to digest and merge faster overall.

@kigawas
Copy link
Contributor Author

kigawas commented Sep 22, 2019

@omershlo
mainly 3 parts

  1. fix clippy warnings and switch to rust 2018
  2. refactor test and demo
  3. minor derive traits change

you can check it by commit

@omershlo
Copy link
Contributor

Hi @kigawas , we recently merged a PR containing known issues raised by the audit. Can you take the latest v0.2.4 into this PR?

@oleiba do you still have open issues here?

assert_eq!(decom_vec.len(), params.share_count);
assert_eq!(bc1_vec.len(), params.share_count);
assert_eq!(decom_vec.len() as u16, params.share_count);
assert_eq!(com_vec.len() as u16, params.share_count);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think this rename is necessary.

if test_b_vec_and_com {
Ok({
let gamma_sum = tail.fold(head.g_gamma_i, |acc, x| acc + x.g_gamma_i);
gamma_sum * delta_inv
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please don't remove the R or otherwise add a comment that this is R

@omershlo
Copy link
Contributor

@kigawas I see you changed the param file to params.json. In that case can you also provide such file in the repo (replacing the old params file) ?

@omershlo
Copy link
Contributor

I finished my review. I approve once the comments above are resolved.
I am also wondering if we should add to this pr #72 ... wdyt?

@omershlo omershlo merged commit 019ed6a into ZenGo-X:master Nov 3, 2019
@kigawas kigawas deleted the keygen-clippy branch November 8, 2019 07:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Consider migrating to Rust 2018 t and n should not be usize
3 participants