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

Add ConstantTimeSelect trait #454

Merged
merged 2 commits into from
Dec 17, 2023
Merged

Add ConstantTimeSelect trait #454

merged 2 commits into from
Dec 17, 2023

Conversation

tarcieri
Copy link
Member

We can't impl subtle::ConditionallySelectable for Boxed* types due to a bound on Copy.

I've proposed various ways to try to fix this upstream, e.g. dalek-cryptography/subtle#118, from which the ConstantTimeSelect trait has been extracted. It provides the same API as
ConditionallySelectable but without the Copy bound.

A blanket impl of ConstantTimeSelect for all ConditionallySelectable types means that all stack allocated types can continue to use ConditionallySelectable and will receive an impl of ConstantTimeSelect as well.

A bound on ConstantTimeSelect has been added to the Integer trait as well, allowing it to be used on all *Uint types in this crate with Integer as the trait abstraction.

We can't impl `subtle::ConditionallySelectable` for `Boxed*` types due
to a bound on `Copy`.

I've proposed various ways to try to fix this upstream, e.g.
dalek-cryptography/subtle#118, from which the `ConstantTimeSelect` trait
has been extracted. It provides the same API as
`ConditionallySelectable` but without the `Copy` bound.

A blanket impl of `ConstantTimeSelect` for all `ConditionallySelectable`
types means that all stack allocated types can continue to use
`ConditionallySelectable` and will receive an impl of
`ConstantTimeSelect` as well.

A bound on `ConstantTimeSelect` has been added to the `Integer` trait as
well, allowing it to be used on all `*Uint` types in this crate with
`Integer` as the trait abstraction.
@tarcieri
Copy link
Member Author

This of course doesn't work with the CtOption combinators (most of which are arguably better implemented without it), but with #440 introducing a new const-friendly CtOption-alike we can potentially work around that.

@tarcieri
Copy link
Member Author

Merging this so we have some sort of trait-based abstraction over these types

@tarcieri tarcieri merged commit e7bcff7 into master Dec 17, 2023
16 checks passed
@tarcieri tarcieri deleted the constant-time-select-trait branch December 17, 2023 23:06
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

1 participant