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

call fe_verfiy for not normalized field element in fe_set_b32 #1061

Closed
siv2r opened this issue Jan 3, 2022 · 7 comments
Closed

call fe_verfiy for not normalized field element in fe_set_b32 #1061

siv2r opened this issue Jan 3, 2022 · 7 comments

Comments

@siv2r
Copy link
Contributor

siv2r commented Jan 3, 2022

#ifdef VERIFY
r->magnitude = 1;
if (ret) {
r->normalized = 1;
secp256k1_fe_verify(r);
} else {
r->normalized = 0;
}
#endif

Shouldn't the call to secp256k1_fe_verify come after the else block?

@real-or-random
Copy link
Contributor

This was changed in 34a67c7. I believe this is this intentionally to optimize the tests. Can you check if the tests take noticeably longer if the fe_verify is moved after the else block?

@siv2r
Copy link
Contributor Author

siv2r commented Jan 11, 2022

build commands: ./autogen.sh && ./configure && make -j13
Execution time (in seconds) of tests.c for three iterations (on 64-bit, i7-8750H). I used gettime_i64 function to measure the execution time. You can find my complete code here.

branch min avg max
master (fe_verify inside if block) 145.94 146.26 146.72
bench-tests (fe_verify after else block) 145.74 146.04 146.27

There isn't much difference in the execution time.

@real-or-random
Copy link
Contributor

Oh I think the time command would have been fine-grained enough for the tests. :)

Yeah, I mean if the difference is below a second, I'd say it's reasonable to always do the verify.

@siv2r
Copy link
Contributor Author

siv2r commented Jan 12, 2022

Makes sense. The change required here is relatively small. I will check other parts of the code for similar issues and bundle them up in a PR.

@siv2r
Copy link
Contributor Author

siv2r commented Jan 12, 2022

Oh I think the time command would have been fine-grained enough for the tests. :)

I didn't know such a command existed. I initially tried to use clock_gettime() for nanosecond precision..xD. It didn't work since c89 does not seem to support it.

@real-or-random
Copy link
Contributor

Maybe this could be solved in #1062 ? I think it will be similar to some changes proposed there.

real-or-random added a commit that referenced this issue Aug 17, 2023
…k` calls (in tests)

54058d1 field: remove `secp256k1_fe_equal_var` (siv2r)
bb4efd6 tests: remove unwanted `secp256k1_fe_normalize_weak` call (siv2r)

Pull request description:

  Fixes #946 and #1061

  Changes:
  - removes unwanted `fe_normalize_weak` calls to the second argument of `fe_equal`
  - removes `fe_equal_var`

ACKs for top commit:
  real-or-random:
    utACK 54058d1
  jonasnick:
    ACK 54058d1

Tree-SHA512: 89bfd1c205f760d0736b995adebb96d15b0df0a42ece25885c57ae7f4318f6816eb009a7fe94b5987a4cbb8588f0fffbdc275234b406a2d1f80d7695b4bd89db
@real-or-random
Copy link
Contributor

This has been resolved by #1062.

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

No branches or pull requests

2 participants