Skalman pok new interface #29

drskalman · 2021-02-08T15:13:11Z

PoP: using schnorr proof.
Moving the backend to arkworks.
Remove some redundants trait.

more adaptions.

Commenting out lots of problematic types to make engine.rs compiles.

in zexe

… compiles but not the tests.

…y objects

but two tests fail.

message test

…r-pok

…into skalman-pok-new-interface

secret key

order to resolve CountSigned test failure.

- Removed old secret serialization and derive it from Arkworks serialization

burdges · 2021-02-09T00:18:50Z

src/bls_pop.rs

+
+        let mut k_as_hash = <H as Digest>::new().chain(r_point_as_bytes).chain(message.0).finalize();
+	    let random_scalar : &mut [u8] = k_as_hash.as_mut_slice();
+	    random_scalar[31] &= 31; // BROKEN HACK DO BOT DEPLOY


right this part.. what is the group order again? they just added hash to field, right?

Yes they did. It wasn't merged at the time, but I think it should have made it to the master/main now: #32 .

burdges · 2021-02-09T00:20:19Z

src/bls_pop.rs

+        let mut r_point_as_bytes = Vec::<u8>::new();
+        r_point.into_affine().write(&mut r_point_as_bytes).unwrap();
+
+        let mut k_as_hash = <H as Digest>::new().chain(r_point_as_bytes).chain(message.0).finalize();


one should include the public key here.

M was public key before but I thought we decided to replace with any arbitary message which can be public key as well. You want public key to be a mandatory part of the message?

burdges · 2021-02-09T00:22:23Z

src/bls_pop.rs

+
+impl<E: EngineBLS, H: Digest> ProofOfPossessionGenerator<E,H> for SecretKey<E> {
+
+    fn generate_pok(&self, message: Message) -> SchnorrProof<E> {


I'm tempted to use a transcript abstraction instead of Message like in schnorrkel, ring-vrf, and now the apk crate. Message made sense for BLS signatures message. And maybe still does. I do not see much point in a schnorr proof.

We should maybe make this PoK do both G1 and G2 if we're going that route, no? I guess that's a seperate thing that depends upon only Engine. Ugh.

Made issues #30 and #31 to follow up with these.

burdges · 2021-02-09T00:24:35Z

src/lib.rs

-}
+//     // #[test]
+//     // fn foo() { }
+// }


We can do global tests in a follow up, not sure what's not tested yet actually.

burdges · 2021-02-09T00:27:23Z

src/verifiers.rs


-use pairing::{CurveAffine, CurveProjective};  // Engine, Field, PrimeField, SqrtField
+use ark_ec::ProjectiveCurve;
+use ark_serialize::{CanonicalSerialize};

 use super::*;



We'll keep these I guess, and they could be useful if collecting by gossip, but we do not envision using them ourselves, and maybe https://eprint.iacr.org/2021/005 provides interesting ides for gossip situations.

Hmm, what do you mean by "these"?

I meant the whole file with these aggregate BLS verifiers.

burdges · 2021-02-09T00:31:00Z

src/single.rs

+            #[inline]
+            fn uncompressed_size(&self) -> usize {
+                self.0.into_affine().uncompressed_size()
+            }


Can we just pass this through to the CanonicalSerialize on the underlying type?

I'm not sure what I think of this CanonicalSerialize trait overall yet, but I guess it's what arkworks does. Is it what celo does?

hmm, we can't. because projective points can't be canonically serialized (and hence ProjectiveCurve trait does not implement CanonicalSerialize. I think turn them into affine and call the serialization functions is the closest thing we do. I can look into celo's approach though.

Are we serializing projective without going through affine here? Why? Did i do that?

No, we go through affine as in self.0.into_affine() . What I meant was that we just can't simply derive CanonicalSerialize for the Public/Private key because we need to perform this into_affine() step manually.

You basically reimplemented serialization from scratch, there was no official serialization in the original pairing library.

We could pass this through to the underlying affine curve then maybe?

I'll just merge this and then we can make another issue for passing these through.

We could pass this through to the underlying affine curve then maybe?

I thought I was doing that. Could you show me what is the proper way of doing it?

burdges · 2021-02-09T00:32:53Z

We should discuss the above things, but I'm satisfied this moves in the correct direction, so we can merge it and then focus on more detailed issues.

drskalman and others added 30 commits September 24, 2020 12:34

Initial signing implementation stuck at pairing upgrade kerfuffle

fa93daf

Moving from paired to zexe/algebra-core as the pairing provider

ba6a26f

Introduced PublicKeyPrepared and SignaturePrepared types.

82ef141

Publickey/SignaturePrepared types added to the engine. Still needs

db8147f

more adaptions.

Reintroducing Base fields to EngineBLS.

54f9808

Commenting out lots of problematic types to make engine.rs compiles.

commented out single and verification etc just to make engine to compile

ec0106c

Simplifying EngineBLS functions due to change in miller loop args type

42b6e23

in zexe

Resolve From not implemented in single.rs and other errors

5f193aa

*_assign

cf94ee1

single.rs upgraded to use zexe and compiles.

8d44845

re-include verifier.rs and replace old affine prepared called

3839aa6

verify_with_distinct_messages migrated

881516f

verifier.rs now compiles depending on zexe

78b6b2b

bit.rs, pop.rs and distinct.rs moved to zexe backend

c004245

port delinear.rs successfully to zexe backend and the whole library…

6356a8b

… compiles but not the tests.

Move 'TinyBLS' to zexe backend

44ebfab

Add macro which implement de/serialization for Signature and PublicKe…

684df14

…y objects

Move zbls macros to new serialization paradaigm, cargo test compiles

da4ce55

but two tests fail.

Fix the bug for over-allocating the serialization vector in signle

acc3b73

message test

Merge branch 'skalman-zexe-unprepared-serialized' into skalman-schnor…

a482de8

…r-pok

Fix wrong constant hash to curve function

3821a36

Merge branch 'skalman-zexe-unprepared-serialized' into skalman-schnor…

2004a0d

…r-pok

Resolved all errors for sign_pok with test except for 1

ed5223d

Resolve type specification error (courtesy of @lamafab )

e07e15a

Change BLSSchnoorProof structure and implement test_verify_pok

7e2aaa3

Fix pok signing error by zeroing high bits of randomness

d54a09f

break PoK operation in to two traits

2281381

pass schnorr PoP verification test

a8761d8

break PoK operation in to two traits

628c61e

Adapt bls_pop to new model and make tests pass

76873f5

drskalman added 7 commits January 8, 2021 12:47

Merge branch 'skalman-pok-new-interface' of https://github.com/w3f/bls …

f4d137c

…into skalman-pok-new-interface

add the ability of using arbitary message to produce the PoP of a

b6ba31d

secret key

add message for when countsig fails

5460394

clean Cargo.toml and replace double with double_in_place in bit.rs in

5db35d3

order to resolve CountSigned test failure.

Moving from Zexe to Arkwork, there is still problem with serialization

e90d26e

- Resolve error due to dependacy moved from Zexe to Arkworks

8b319e3

- Removed old secret serialization and derive it from Arkworks serialization

Get rid of all warnings!

2713cd1

drskalman requested a review from burdges February 8, 2021 15:13

drskalman self-assigned this Feb 8, 2021

drskalman mentioned this pull request Feb 8, 2021

Clean up BLS PoP code and prepare it for review #28

Closed

burdges reviewed Feb 9, 2021

View reviewed changes

burdges merged commit 4dbc199 into master Feb 9, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Skalman pok new interface #29

Skalman pok new interface #29

drskalman commented Feb 8, 2021

burdges Feb 9, 2021 •

edited

Loading

drskalman Feb 9, 2021

burdges Feb 9, 2021

drskalman Feb 9, 2021

burdges Feb 9, 2021

burdges Feb 9, 2021

drskalman Feb 9, 2021

burdges Feb 9, 2021

burdges Feb 9, 2021

drskalman Feb 9, 2021

burdges Feb 9, 2021

burdges Feb 9, 2021

drskalman Feb 9, 2021

burdges Feb 9, 2021

drskalman Feb 9, 2021

burdges Feb 9, 2021

burdges Feb 9, 2021

drskalman Feb 22, 2021

burdges commented Feb 9, 2021


		impl<E: EngineBLS, H: Digest> ProofOfPossessionGenerator<E,H> for SecretKey<E> {

		fn generate_pok(&self, message: Message) -> SchnorrProof<E> {

Skalman pok new interface #29

Skalman pok new interface #29

Conversation

drskalman commented Feb 8, 2021

burdges Feb 9, 2021 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

burdges commented Feb 9, 2021

burdges Feb 9, 2021 •

edited

Loading