Skip to content

chore(crypto): CRP-2978 Extend ic-signature-verification for v3 canister ranges#9277

Open
randombit wants to merge 5 commits intomasterfrom
jack/crp-2978
Open

chore(crypto): CRP-2978 Extend ic-signature-verification for v3 canister ranges#9277
randombit wants to merge 5 commits intomasterfrom
jack/crp-2978

Conversation

@randombit
Copy link
Contributor

The interface specification has contained support for sharded canister ranges for some time, but this was not supported in ic-signature-verification.

…ter ranges

The interface specification has contained support for sharded canister ranges for
some time, but this was not supported in ic-signature-verification.
@randombit randombit requested a review from a team as a code owner March 9, 2026 21:34
@github-actions github-actions bot added the chore label Mar 9, 2026
@randombit
Copy link
Contributor Author

I tried creating a testcase for this using ic-certification-testing. For some reason I have yet to determine, my testcase works, in that the new lookup path is hit and the canister ID is considered a match - but the BLS signature on the delegation is rejected, causing an overall failure.

I'll ping Hamish re the inputs he was using since that may be simpler and also more useful as a test than what I have anyway (in terms of testing something from mainnet or testnet rather than entirely synthetic data)

.list_paths()
.iter()
.filter(|path| !path.is_empty())
.try_fold(
Copy link
Contributor

Choose a reason for hiding this comment

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

IIUC, this traverses the entire subtree to collect all labels, then iterate over all labels, deserializes all of them and accumulates all ranges into a vec. Then we do linear search on this vec afterwards.

I'm wondering if we can do this more efficiently, given that the new approach of the canister ranges was introduced precisely to allow for more efficiency through binary searches (see the very end of this: "This facilitates e.g., binary searching.").

Could we maybe do something similar to this?

Most likely the published ic-certification crate (which is different from our ic-certification crate in the monorepo 🤯) doesn't offer the necessary tooling currently, but maybe we could add it?

Given that the HashTreeNode is public and sorted (labels in left forks are always less than labels in right forks — see the lookup_label implementation), maybe could even write a custom traversal helper that finds the largest label (= the signing canister ID) directly in ic-signature-verification (but I guess extending ic-certification would be cleaner).

WDYT?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah that was pretty lazy. I'm hesitant to make things too complicated here since we do not have particularly thorough test cases at the moment. For now I just changed it to look at each leaf (without copying) and early exit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants