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

Derive comparison traits for all secret key types #485

Merged
merged 1 commit into from
Dec 13, 2022

Conversation

quad
Copy link
Contributor

@quad quad commented Nov 2, 2022

The public key types (DescriptorPublicKey, DescriptorXKey, SinglePubKey, and DefiniteDescriptorKey) all have comparison derivations.

The underlying private key types (bitcoin::PrivateKey, Fingerprint, DerivationPath, DescriptorXKey, and ExtendedPrivKey) all have comparison derivations.

Let's catch 'em all.

@apoelstra
Copy link
Member

Nice! cc @sanket1729 I'd like you to concept ACK before merging this

Copy link
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK 8e781ca

@sanket1729
Copy link
Member

@apoelstra, I see that rust-secp implements PartialOrd, and Ord directly without any constant time guarantees. When did we do that? I thought we deliberately did not do that to avoid side channels.

@sanket1729
Copy link
Member

Don't mind merging this. Should we wait until rust-bitcoin/rust-secp256k1#471 is resolved?

@sanket1729
Copy link
Member

Will merge after #488

@apoelstra
Copy link
Member

@sanket1729 it looks like they appeared in rust-bitcoin/rust-secp256k1#364 where there is no discussion about them :/ maybe we forgot at that time about the pitfalls of Ord on secret key types. I also remember this discussion but I can't find it now and don't remember where we landed.

One thing I do remember saying is that any comparisons of secret keys is likely to be leaky anyway. Like, if you put secret keys into a BTreeMap or something then you know that the first key to be read is likely to be smaller than average, and it doesn't matter whether Ord is constant time. So my feeling was that if we had Ord at all, I wasn't so worried about constant-timeness as I would be for Eq (which I expect to be more frequently used, and to be usually used safely).

Another thing I do remember is that we were considering doing something crazy like, hashing the secret keys and then comparing by hash. But then somebody (kixunil?) pointed out that there are coherency requirements between Eq, Ord and Hash that would make this extremely hard to do, at least efficiently. So maybe there was a discussion about this but it never went anywhere since we couldn't agree on a good path forward?

Copy link
Member

@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

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

ACK 8e781ca

@sanket1729 sanket1729 merged commit f5f22d5 into rust-bitcoin:master Dec 13, 2022
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.

None yet

3 participants