Crates API and documentation #67
Assignees
Comments
|
We should consider to release the crate with the traits which would define API and then use it in own implementations and enable foreign. I'm not sure yet about downsides of this approach aside from some added complexity which would buy uniformity of all implementations. So counter arguments are welcome. |
|
I don't expect most people to use the crate anyways since it'll require custom logic to get the secret key in there and don't know any rust wallets. Agree on adding docs and making name more uniform. |
|
From the top of my head I would name Solana. X) Didn't check Polkadot,
but would place a bet on it too.
…On Sun, Oct 22 2023 at 07:23:45 AM +0000, Yush G ***@***.***> wrote:
I don't expect most people to use the crate anyways since it'll
require custom logic to get the secret key in there and don't know
any rust wallets.
Agree on adding docs and making name more uniform.
—
Reply to this email directly, view it on GitHub
<#67 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/APXLOT65UYH3RHK2KQO3ZATYATCX7AVCNFSM6AAAAAA6KK5PXSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONZUGAYTQNRXGY>.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Got it -- that makes sense, I don't know anything about those. Traits seem fine to me -- the complexity shouldn't be that high on our side right, just implementing the trait twice? As long as almost everything is pub, I'm OK with that. |
|
Can you make a gitbook or mdbook and make this? Also, can you publish a cargo crate -- there should automatically be cargo docs from the docstrings right? |
Yep. Here it's needed to groom the interfaces and write those docstring. |
Divide-By-0
pushed a commit
that referenced
this issue
Feb 15, 2024
* current progress * link to relevant issue * crate name edit * Flat the docs entities * meta information * Update the crate name in `tests` * current progress
Merged
skaunov
added a commit
that referenced
this issue
Feb 28, 2024
See issues #67 and #84 . Few snippets of other paths I considered. ```rust ... [ProjectivePoint::GENERATOR.to_encoded_point(true).as_bytes(), &pk_bytes, enc!(hashed_to_curve)].map(|b| hashers[0].update(b)); for b in [enc!(nullifier), enc![r_point], enc!(hashed_to_curve_r)] { hashers[0].update(b); hashers[1].update(b); } let c = hashers.map(|h| h.finalize()); let c_scalar = c.clone().map(|c_i| NonZeroScalar::reduce_nonzero(U256::from_be_byte_array(c_i))); // Compute s = r + sk ⋅ c let s_scalar = c_scalar.map(|c_scalar_i| NonZeroScalar::new(*r_scalar + *(self.to_nonzero_scalar() * c_scalar_i)) .expect("something is terribly wrong if the nonce is equal to negated product of the secret and the hash")); Ok(PlumeSignatureCombined{ message: msg.to_owned(), pk: pk.into(), nullifier: nullifier.to_point(), v2_c: c[1], v2_s: *s_scalar[1], v1_c: c[0], v1_s: *s_scalar[0], v1_r_point: r_point.into(), v1_hashed_to_curve_r: hashed_to_curve_r.to_point(), }) } } /// Struct holding mandatory signature data for ... PLUME signature #[derive(Debug)] pub struct PlumeSignatureCombined { /// The message that was signed. pub message: Vec<u8>, /// The public key used to verify the signature. pub pk: ProjectivePoint, /// The nullifier. pub nullifier: ProjectivePoint, /// Part of the signature data. pub v2_c: Output<Sha256>, /// Part of the signature data, a scalar value. pub v2_s: Scalar, /// Part of the signature data. pub v1_c: Output<Sha256>, /// Part of the signature data, a scalar value. pub v1_s: Scalar, /// Part of the V1 signature data, a curve point. pub v1_r_point: ProjectivePoint, /// Part of the V1 signature data, a curve point. pub v1_hashed_to_curve_r: ProjectivePoint, } impl PlumeSignatureCombined { pub fn separate(self) -> (PlumeSignature, PlumeSignature) { let (pk, nullifier) = (self.pk, self.nullifier); ( PlumeSignature{ message: self.message.clone(), pk, nullifier, c: self.v1_c, s: self.v1_s, v1specific: Some( PlumeSignatureV1Fields{ r_point: self.v1_r_point, hashed_to_curve_r: self.v1_hashed_to_curve_r } ) }, PlumeSignature{ message: self.message, pk, nullifier, c: self.v2_c, s: self.v2_s, v1specific: None }, ) } } ``` _____________________________________ ```rust pub enum PlumeSignature{ V1(PlumeSignatureV1), V2(PlumeSignatureV2), } pub struct PlumeSignatureV1 { v2: PlumeSignatureV2, v1: PlumeSignatureV1Fields } /// Struct holding mandatory signature data for a PLUME signature. pub struct PlumeSignatureV2 { /// The message that was signed. pub message: Vec<u8>, /// The public key used to verify the signature. pub pk: ProjectivePoint, /// The nullifier. pub nullifier: ProjectivePoint, /// Part of the signature data. pub c: Output<Sha256>, /// Part of the signature data, a scalar value. pub s: Scalar, // /// Optional signature data for variant 1 signatures. // pub v1: Option<PlumeSignatureV1Fields>, } /// struct holding additional signature data used in variant 1 of the protocol. #[derive(Debug)] pub struct PlumeSignatureV1Fields { /// Part of the signature data, a curve point. pub r_point: ProjectivePoint, /// Part of the signature data, a curve point. pub hashed_to_curve_r: ProjectivePoint, } impl signature::RandomizedSigner<PlumeSignatureV1> for SecretKey {} impl signature::RandomizedSigner<PlumeSignatureV2> for SecretKey {} ``` --------- Co-authored-by: skaunov <skaunov@disroot.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Both crates basically lacks documentation, and <./rust-k256> lacks API choices.
Also their
nameare ...temporary.PS It would be nice to think about traits used and reexported so that it would not clash with versions that downstream use. Though most likely Cargo will do its job on it, just it's better to be sure.
This one is more about releasing the crates when things will come to it.
The text was updated successfully, but these errors were encountered: