Deterministic Pedersen secret blinding factor generation #24

davxy · 2024-07-09T10:14:59Z

No description provided.

davxy · 2024-07-10T12:23:30Z

src/pedersen.rs

+        // TODO:is this ok?
+        let cb = S::challenge(&[&input.0, &output.0], ad.as_ref());
+        let b = self.scalar * cb;
+
        // Construct the nonces
        let k = S::nonce(&self.scalar, input);
-        let kb = S::nonce(&k, input);
-        let b = S::nonce(&kb, input);
+        let kb = S::nonce(&b, input);


@drskalman I'd like your opinion on this method of generating the blinding factor (blinding).

In practice:

let cb = challenge([input_point, output_point], aux_data); let blinding = secret_scalar * cb; // Nonces: let k = nonce(secret_scalar, input); let kb = nonce(blinding, input);

I'd like to make it deterministic, so I've used everything I have as input, plus the secret. Everything hashed together somehow (I'm using the challenge function)

The nonces are constructed as defined in the spec here:

https://github.com/davxy/bandersnatch-vrfs-spec/blob/a66a07c3d0bb7605c7272a791359cca2f4fa1a92/specification.md?plain=1#L251-L252

My only doubt is about the blinding factor construction.
Is the way I'm constructing it fine?

challenge and nonce functions I'm using are defined here (both also referenced in our bandersnatch spec)

challenge:

ark-ec-vrfs/src/utils.rs

Line 151 in 2941337

pub fn challenge_rfc_9381<S: Suite>(pts: &[&AffinePoint<S>], ad: &[u8]) -> ScalarField<S> {

nonce:

ark-ec-vrfs/src/utils.rs

Line 184 in 2941337

pub fn nonce_rfc_8032<S: Suite>(sk: &ScalarField<S>, input: &AffinePoint<S>) -> ScalarField<S> {

Also note that I've changed how kb is computed

drskalman · 2024-07-25T13:48:48Z

src/pedersen.rs

@@ -49,10 +49,13 @@ impl<S: PedersenSuite> Prover<S> for Secret<S> {
        output: Output<S>,
        ad: impl AsRef<[u8]>,
    ) -> (Proof<S>, ScalarField<S>) {
+        // TODO:is this ok?
+        let cb = S::challenge(&[&input.0, &output.0], ad.as_ref());
+        let b = self.scalar * cb;


Why do you multiply here? Why do you need the algebraic structure? if b is supposed to completely [pseudo]random then why not do the nonce(scalar, cb) instead?

We don't need any algebraic relation. I just tried to mix the thing up with the secret scalar as well.
The nonce function takes two params: 1st a scalar, 2nd a point.
cb is a scalar as well, so I can't use it as second param to nonce. So I ended up just multiplying the two.
Maybe the challenge output is already sufficient? As it also mixes up the output which in fact is obtained using the secret (i.e. output = input*secret).

To recap, I'd like to use what I have at the begin of Pedersen prove function to deterministically generate a pseudo random secret blinding factor b.

At entry point, this is what we have available:

input point

output point which in practice is input * secret

ad (additional data) bytes

secret scalar

Functions we can use:

challenge function, which takes a sequence of points and a byte array and returns a scalar

nonce function, which takes a scalar and a point and returns a scalar

hey @elizabeth-crites, can I have your opinion please ? Ty

I don't think challenge only is enough, first I don't know if either input and output are secret (I should but I haven't checked) plus, while challenge should be unpredictable, I don't think by definition it needs to be hiding.

Moreover, challenges are supposed to be publicaly computable so using only challenge with secret input results in a confusing code.

The function to generate deterministic "randomness" in RFC 8032 gets both inputs as bytes, so you could potentially use the definition in RFC 8032 (without involving the point on the curve -> byte steps).

Another point @elizabeth-crites brought up is that if you make the process deterministics then an attacker might be able to force the same input and then you end up with the same output so they can find out who has signed the second time. So my guess is that we want this VRF to stay anonymous even if the attacker plays the same input multiple time.

In this way it seems that making b deterministic fundamentally breaks the anonynmity property.

Yeah using only the challenge was absolutely incorrect, indeed I've updated the thing to also plug the secret scalar into the computation.

For what concerns the anonymity considerations, you're right I'll make it deterministic only for test-vectors generation

I thought a bit more about this. The VRF signature contains the VRF output which is always k*I (with k the secret scalar and I the vrf input point). Thus the anonymity reasoning thing doesn't here. I.e. you can still link the signer of two identical inputs (as the vrf output is the same regardless of the blinding factor randomness).

BTW I've finally decided to let the user pass the blinding factor. So its not the library responsibility to construct it

I guess you are right, maintaining annonymity for the same replayed input then is not part of the threat model.

BTW I've finally decided to let the user pass the blinding factor. So its not the library responsibility to construct it

I'd speculate that would make some people who don't have faith in user (of the library)'s ability in generating a sufficient random number uncomfortable. But it does simlifies the Spec. You don't generate the secret key for the user either, so that should be OK. Plus I see you are offering the default to generate deterministic psudo-randomness.

davxy · 2024-07-25T18:16:51Z

src/pedersen.rs

+    /// Pedersen blinding factor.
+    ///
+    /// Default implementation is deterministic and inspired by the RFC-9381 challenge procedure.
+    fn blinding(
+        secret: ScalarField<Self>,
+        pts: &[&AffinePoint<Self>],
+        ad: &[u8],
+    ) -> ScalarField<Self> {
+        const DOM_SEP_START: u8 = 0xC2;
+        const DOM_SEP_END: u8 = 0x00;
+        let mut buf = [Self::SUITE_ID, &[DOM_SEP_START]].concat();
+        pts.iter().for_each(|p| {
+            Self::Codec::point_encode(p, &mut buf);
+        });
+        buf.extend_from_slice(ad);
+        buf.push(DOM_SEP_END);
+        let hash = &utils::hash::<Self::Hasher>(&buf);
+        let c = ScalarField::<Self>::from_be_bytes_mod_order(hash);
+        secret * c
+    }


@drskalman @elizabeth-crites

I wrapped up the procedure here. Is a "default" and the user can eventually overwrite it.
(but we also have to consider that most of the folks will stick to the defaults).

The procedure is inspired by the RFC-9831 challenge to mix up all the available inputs we have when prove is called (see below). And then we finally multiply the resulting scalar by the secret key scalar.

If this is not considered a good default then I have to modify the interface to take the blinding factor from the user, because I don't think we can do a lot better with what we have

@AlistairStewart thinks multiplying secret key with the transcript point is OK. I still would prefer a non-algebraic way of mixing the secret key (like they generate deterministic randmoness in eddsa) when you don't need the algebraic structure at all.

Deterministic pedersen secret generation

d6527c4

davxy force-pushed the pedersen-secret-gen branch from 737ca2c to d6527c4 Compare July 10, 2024 11:52

davxy added 2 commits July 10, 2024 14:02

Regenerate vectors

2c3196e

...

81f3167

davxy commented Jul 10, 2024

View reviewed changes

davxy marked this pull request as ready for review July 10, 2024 12:40

drskalman reviewed Jul 25, 2024

View reviewed changes

davxy added 5 commits July 25, 2024 17:29

Merge branch 'main' into pedersen-secret-gen

7429588

Allow user to choose blinding factor generation technique

574b4be

Revert cruft

ee3ba58

Keep the default simple

7edabbf

Don't call into challenge (as it may truncate the hash)

bc45358

davxy changed the title ~~Deterministic Pedersen secret generation~~ Deterministic Pedersen secret blinding factor generation Jul 25, 2024

Fix the stupidest thing ever

7b3c054

davxy commented Jul 25, 2024

View reviewed changes

davxy added 2 commits July 26, 2024 12:41

Cleanup

85a1e71

Merge branch 'main' into pedersen-secret-gen

3947555

davxy merged commit 849c1d4 into main Jul 26, 2024
5 checks passed

davxy deleted the pedersen-secret-gen branch July 26, 2024 10:57

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Deterministic Pedersen secret blinding factor generation #24

Deterministic Pedersen secret blinding factor generation #24

davxy commented Jul 9, 2024

davxy Jul 10, 2024 •

edited

Loading

davxy Jul 10, 2024

drskalman Jul 25, 2024

davxy Jul 25, 2024

davxy Jul 25, 2024 •

edited

Loading

drskalman Jul 25, 2024

drskalman Jul 25, 2024

davxy Jul 25, 2024 •

edited

Loading

davxy Jul 26, 2024 •

edited

Loading

davxy Jul 26, 2024

drskalman Aug 1, 2024

drskalman Aug 1, 2024

davxy Jul 25, 2024

drskalman Aug 1, 2024

Deterministic Pedersen secret blinding factor generation #24

Deterministic Pedersen secret blinding factor generation #24

Conversation

davxy commented Jul 9, 2024

davxy Jul 10, 2024 • 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

davxy Jul 25, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davxy Jul 25, 2024 • edited Loading

Choose a reason for hiding this comment

davxy Jul 26, 2024 • 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

davxy Jul 10, 2024 •

edited

Loading

davxy Jul 25, 2024 •

edited

Loading

davxy Jul 25, 2024 •

edited

Loading

davxy Jul 26, 2024 •

edited

Loading