Skip to content

Conversation

theStack
Copy link
Contributor

In several calls of the internal function secp256k1_eckey_pubkey_serialize, the public API flag SECP256K1_EC_COMPRESSED is passed, which is meant to be only used for the public function secp256k1_ec_pubkey_serialize. It works as intended in all of those cases (it wouldn't for SECP256K1_EC_UNCOMPRESSED though), but it's still kind of a type mismatch that can't be detected by the compiler. To avoid cases like this in the future, a VERIFY_CHECK is added that the compressed parameter needs to be either 0 or 1.

In several calls of the internal function
`secp256k1_eckey_pubkey_serialize`, the public API flag
`SECP256K1_EC_COMPRESSED` is passed, which is meant to be only used for
the public function `secp256k1_ec_pubkey_serialize`. It works as
intended in all of those cases (it wouldn't for `..._UNCOMPRESSED`
though), but it's still kind of a type mismatch that can't be detected
by the compiler.  To avoid cases like this in the future, a VERIFY_CHECK
is added that the `compressed` parameter needs to be either 0 or 1.
@apoelstra
Copy link
Contributor

LGTM

Copy link
Collaborator

@real-or-random real-or-random left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Concept ACK

}

static int secp256k1_eckey_pubkey_serialize(secp256k1_ge *elem, unsigned char *pub, size_t *size, int compressed) {
VERIFY_CHECK(compressed == 0 || compressed == 1);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure if we want to touch this upstream file. It's also a nice goal to keep the diff to upstream minimal. Ideally, the diff to upstream would just be added modules and changes to build system, README, etc... But yeah, we've modified upstream files in the past. If we think that this is a reasonable change, we could PR it to upstream, of course.

Same is true for the modification to secp256k1.c

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should just rebase on upstream's musig module now.

theStack added a commit to theStack/secp256k1 that referenced this pull request Dec 2, 2024
Due to similarity to the public API function `secp256k1_ec_pubkey_serialize`,
public API flags like `SECP256K1_EC_COMPRESSED` are sometimes mistakingly
passed to newly proposed code (this is currently the case for several modules in
secp256k1-zkp, see BlockstreamResearch/secp256k1-zkp#300).
which is currently not detected. To avoid this in the future, a VERIFY_CHECK
is added to check that the `compressed` argument is either 0 or 1.
real-or-random added a commit to bitcoin-core/secp256k1 that referenced this pull request Feb 24, 2025
…serialize`

1823594 Verify `compressed` argument in `secp256k1_eckey_pubkey_serialize` (Sebastian Falbesoner)

Pull request description:

  Due to similarity to the public API function `secp256k1_ec_pubkey_serialize`, public API flags like `SECP256K1_EC_COMPRESSED` are sometimes mistakingly passed to `secp256k1_eckey_pubkey_serialize` in newly proposed code (this is currently the case for several modules in secp256k1-zkp, see BlockstreamResearch/secp256k1-zkp#300), which is currently not detected. To avoid this in the future, a VERIFY_CHECK is added to check that the `compressed` argument is either 0 or 1.

ACKs for top commit:
  real-or-random:
    utACK 1823594
  stratospher:
    ACK 1823594. Got tests failures when passing public API flags to `secp256k1_eckey_pubkey_serialize`.

Tree-SHA512: ca542afc87f33e436ba33dc55b285dfe3759007c446ef94503bc1044c7a0a7f7b2208ae82e2c9743fc5fa38cf386127f3fbfa02d2c242f28fab3041ee46f153b
@theStack
Copy link
Contributor Author

Closing this, as a corresponding PR was opened and merged in upstream (see bitcoin-core/secp256k1#1642), i.e. it will be available here once a rebase on v0.7.0 (or later) is done.

@theStack theStack closed this Aug 31, 2025
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.

3 participants