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

Rust 2018 & secp256k1 improvements #61

Open
wants to merge 12 commits into
base: master
Choose a base branch
from

Conversation

kigawas
Copy link
Contributor

@kigawas kigawas commented Sep 2, 2019

fix #62

@omershlo
Copy link
Contributor

omershlo commented Sep 2, 2019

What is the impact of this change? looks like you created more LOC

@kigawas
Copy link
Contributor Author

kigawas commented Sep 2, 2019

@omershlo
No external or internal impact. Just replace the rust 2015 style #[macro_use] extern crate serde_derive with explicit use serde::{Serialize, Deserialize}

And some Secp256k1Point -> Self

@kigawas kigawas mentioned this pull request Sep 4, 2019
@kigawas kigawas changed the title Remove extern crate Rust 2018 Sep 5, 2019
@kigawas
Copy link
Contributor Author

kigawas commented Sep 5, 2019

ready to review & merge

@kigawas kigawas changed the title Rust 2018 Rust 2018 & secp256k1 improvements Sep 5, 2019
@djc
Copy link
Contributor

djc commented Sep 5, 2019

I don't think replacing #[macro_use] for serde_derive with a bunch of explicit imports is really an improvement in this case. Otherwise I really like the cleanups that make the code more idiomatic.

@kigawas
Copy link
Contributor Author

kigawas commented Sep 5, 2019

"explicit is better than implicit"

Some(BigInt::from(&y_vec[..]))
}

fn from_bytes(bytes: &[u8]) -> Result<Secp256k1Point, ErrorKey> {
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 function may be the most refactored one, the logic is basically the same, except directly sending 65 or 33 bytes to secp256k1 lib

Copy link
Contributor Author

Choose a reason for hiding this comment

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

for > 65 bytes input, the necessity of taking its first 64 bytes should be reconsidered

Copy link
Contributor Author

Choose a reason for hiding this comment

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

though I just keep the logic as same as before

v.extend(BigInt::to_vec(&self.y_coor().unwrap()));
v
fn pk_to_key_slice(&self) -> Vec<u8> {
self.ge.serialize_uncompressed().to_vec()
Copy link
Contributor Author

Choose a reason for hiding this comment

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

less computation but the vec length should always be 65 bytes

}
}
}

static mut CONTEXT: Option<Secp256k1<VerifyOnly>> = None;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

replaced by lazy_static

@@ -97,19 +108,16 @@ impl Zeroize for Secp256k1Scalar {
}

impl ECScalar<SK> for Secp256k1Scalar {
fn new_random() -> Secp256k1Scalar {
let mut arr = [0u8; 32];
thread_rng().fill(&mut arr[..]);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

the private key may not be valid, should just use library's new function

Copy link
Contributor Author

@kigawas kigawas Sep 13, 2019

Choose a reason for hiding this comment

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

the probability of getting invalid key is not high, but it's not zero

ECPoint::add_point(self, &minus_point.get_element())
}

fn from_coor(x: &BigInt, y: &BigInt) -> Secp256k1Point {
Copy link
Contributor Author

@kigawas kigawas Sep 13, 2019

Choose a reason for hiding this comment

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

another function replaced by succinct refactored version

@kigawas
Copy link
Contributor Author

kigawas commented Sep 13, 2019

I've added some notes on the part with possible logic change
Hope it can help you guys review

@kigawas
Copy link
Contributor Author

kigawas commented Dec 23, 2019

@omershlo
Do you have time to review again?

@omershlo omershlo self-requested a review December 23, 2019 09:50
@omershlo
Copy link
Contributor

sure

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.

Generating random secret key for secp256k1 is not correct
3 participants