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

Avoid using out-of-bounds field elements (in impossible cases) #289

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

real-or-random
Copy link
Collaborator

secp256k1_fe_set_b32_limit says that when it returns 0, one is not allowed to use the resulting output value.

This refactors the code so that 0 is returned early (indicating failure) in cases where sha256 would output an out-of-bounds hash value. This makes secp256k1_generator_generate_internal variable-time in its "t" argument, but this not a problem because this value is public in applications.

Note: This situation is cryptographically impossible to occur.

Alternative to #282. cc @roconnor-blockstream What do you think?

secp256k1_fe_set_b32_limit says that when it returns 0, one is not allowed to use
the resulting output value.

This refactors the code so that 0 is returned early (indicating failure) in cases
where sha256 would output an out-of-bounds hash value. This makes
secp256k1_generator_generate_internal variable-time in its "t" argument,
but this not a problem because this value is public in applications.

Note: This situation is cryptographically impossible to occur.

Co-authored-by: Russell O'Connor <roconnor@blockstream.io>
@roconnor-blockstream
Copy link
Contributor

Seems okay to me if you folks are okay with the variable time in these (impossible) cases.

@real-or-random
Copy link
Collaborator Author

Seems okay to me if you folks are okay with the variable time in these (impossible) cases.

AFAIU, we should be okay even if the cases were more likely. The derivation of generators should only be a public computation (except maybe blinding), but it will be nice if @apoelstra can confirm that I haven't overlooked anything in this argument.

@roconnor-blockstream
Copy link
Contributor

I agree with you, except that the code seems to have been clearly and deliberately written to be constant time for some reason.

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.

2 participants