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

Handle invalid inputs consistently with respect to constant-time #1621

Open
jonasnick opened this issue Oct 21, 2024 · 0 comments
Open

Handle invalid inputs consistently with respect to constant-time #1621

jonasnick opened this issue Oct 21, 2024 · 0 comments
Labels
meta/development processes, conventions, developer documentation, etc. refactor/smell

Comments

@jonasnick
Copy link
Contributor

Right now, we have two different ways of handling invalid inputs in constant-time functions:

  1. The function is constant-time, even for invalid inputs. For example, secp256k1_schnorrsig_sign_internal continues with the signing procedure even if keypair_load fails (which happens when the keypair is unitialized):
    ret &= secp256k1_keypair_load(ctx, &sk, &pk, keypair);
    ...
    return ret;
    
    This works because even if secp256k1_keypair_load fails, valid values (sk=1, pk=G) are returned.
  2. The function is constant-time only for valid inputs. For example, in secp256k1_musig_partial_sign, we have
    if (!secp256k1_keypair_load(ctx, &sk, &keypair_pk, keypair)) {
        secp256k1_musig_partial_sign_clear(&sk, k);
        return 0;
    }
    
    This works because the return value of keypair_load is declassified.

I think we should make functions only constant-time with respect to valid inputs. This leads to more readable and maintainable code (due to fewer ret &=). Calling functions with invalid inputs (such as an unitialized keypair) should never happen outside of development.

Whatever version we're choosing, we should document it in CONTRIBUTING.md.

@jonasnick jonasnick added refactor/smell meta/development processes, conventions, developer documentation, etc. labels Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta/development processes, conventions, developer documentation, etc. refactor/smell
Projects
None yet
Development

No branches or pull requests

1 participant