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

Could Field::pow_vartime take a slice of word-sized "limbs" as the exponent? #85

Open
tarcieri opened this issue Jun 13, 2022 · 1 comment

Comments

@tarcieri
Copy link
Contributor

Over on RustCrypto/traits#1024 we're discussing how to represent a parameter which is ultimately passed to Field::pow_vartime.

I was suggesting representing it as a crypto_bigint::UInt which internally uses 32-bit limbs on 32-bit platforms and 64-bit limbs on 64-bit platforms.

Field::pow_vartime accepts a type that impls AsRef<[u64]> as an exponent, regardless of the target pointer width.

I think it might make sense to allow customizing that in some way to make it easier to support 32-bit limbs on 32-bit platforms.

For example, PrimeFieldBits::ReprBits makes this possible. I'm curious if a similar associated type could be added to describe an array-of-limbs which would let implementations vary the word size based on the target.

(and really, in practice I'd use the same type as PrimeFieldBits::ReprBits)

@str4d
Copy link
Member

str4d commented Oct 31, 2022

ReprBits representing the word size of the bitvec representation only exists because of limitations in the bitvec API that force it to use [WORD_TYPE; ceildiv(N, size(WORD_TYPE))] as the representation. Once bitvec supports representing an actual [bool; N] then ReprBits will be replaced by that.

Regarding Field::pow_vartime (and the new Field::pow), what we need is access to the bit representation of the exponent. So we could just migrate these APIs to use bitvec which would be perfect for this. However, that would move Field::pow* behind the bits feature flag which is less desirable. But I also don't really fancy duplicating a bunch of the logic that bitvec provides for this (that was the whole reason the bitvec dependency was added in the first place: to replace some slow semantically-equivalent logic).

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

No branches or pull requests

2 participants