feat: support U384 in scalar arithmetic
Description
Implement Reduce and ReduceNonZero traits for U384 in Scalar, update tests to cover new cases.
Fixed #1199
The integer size needs to be a multiple of the limb size. 352-bits is 32-bits * 11, however it isn't evenly divisible by 64-bits
@tarcieri @daxpedda
Right, so U352 per FIPS but i checked the crypto-bigint source - no U352 available, only U192, U224, U256, U384, U448, U512, etc. U384 is the closestr we've got and it actually divides evenly into both 32-bit (12 limbs) and 64-bit (6 limbs).
Should U384 be fine for us or am i missing something?
It is fine, was my bad.
Please refrain from explicit pinging for just a regular answer. Thanks.
One complication here is I'd like to attempt to migrate to a generic field element implementation (#1311) which wouldn't support bespoke reduce impls like this, and would only support generic zero and nonzero reductions for a modulo-sized integer and a double sized "wide" integer.
I can potentially merge this for now, I'm just saying I can't guarantee it will stick around, and it would be up to the caller to concat zeros to make a U512, then reduce.
One complication here is I'd like to attempt to migrate to a generic field element implementation (#1311) which wouldn't support bespoke reduce impls like this, and would only support generic zero and nonzero reductions for a modulo-sized integer and a double sized "wide" integer.
I can potentially merge this for now, I'm just saying I can't guarantee it will stick around, and it would be up to the caller to concat zeros to make a U512, then reduce.
Makes sense! This won't fit the generic architecture. U384 -> U512 conversion is cleaner.
I'm cool with merging this as-is. When the generic implementation lands, users can just do the zero-padding and use standard reduction I guess