MulMod not implemented and not properly documented

[haslersn]

It would be nice if the trait MulMod could be implemented.

Furthermore, the current documentation (v0.3.2) states that mul_mod

Requires p_inv = -(p^{-1} mod 2^{BITS}) mod 2^{BITS} to be provided for efficiency.

However, any even p is not invertible. An even p might be used e.g. when computing over a ring rather than a prime field. So, how should p_inv be set if p is even?

[tarcieri]

It would be nice if the trait MulMod could be implemented.

We attempted to, and the trait still being around is a vestige of that. See:

• experimental: add modulo operations to UInt utils#510
• crypto-bigint: add modulo operations to UInt utils#561

The attempted implementation was incorrect, so it did not land with the rest of the modular arithmetic. It would be beneficial for quite a few projects if we could get it working, though.

So, how should p_inv be set if p is even?

The trait in its current form is specialized to a Montgomery reduction, where typically the modulus is odd.

I'm not terribly familiar with how to do a Montgomery reduction with an even modulus (in all of the @RustCrypto project's applications which could benefit from a generic MulMod the modulus is prime).

Here's a paper I found on Montgomery reductions with an even modulus: http://www.people.vcu.edu/~jwang3/CMSC691/j34monex.pdf

[haslersn]

For an even modulus m one can probably do the following: Decompose m =: 2^k * n such that n is odd. Then perform the multiplication separately mod 2^k and mod n, and combine the results using CRT. But maybe it doesn't work, because the recombination again requires multiplication mod m?

[haslersn]

The trait in its current form is specialized to a Montgomery reduction

@tarcieri Wikipedia says:

The need to convert a and b into Montgomery form and their product out of Montgomery form means that computing a single product by Montgomery multiplication is slower than the conventional or Barrett reduction algorithms.

Did you take this into account when chosing Montgomery multiplication?

[haslersn]

Looking at the old implementation, it looks like it doesn't bring the number into Montgomery form before calling mont_reduce. Maybe that's the reason why it didn't work back then?

[tarcieri]

Yes, that is definitely why it didn't work.

We use both Montgomery and Barrett reductions in the https://github.com/rustcrypto/elliptic-curves crates (for base and scalar field elements respectively, although the latter only for p256) and the fact we have modular multiplication implemented already on a base/scalar field-by-field basis means we haven't been particularly motivated to implement a generic solution in crypto-bigint yet, although it would hypothetically be useful for migrating the dsa and rsa crates off of num-bigint-dig.

For the elliptic curve crates specifically we generally perform a sequence of operations on field elements in Montgomery form, and thus the overhead of converting to/from Montgomery form is ammortized.

There's a question of how to expose values in Montgomery form. There have been various problems with using the same type for both, namely confusing which form a particular value/field element is in. As such I've largely moved the crates to where the crypto-bigint::UInt is used to represent canonical form, and the respective FieldElement types (which are UInt internally) are always in Montgomery form. This makes the conversions type safe.

I'd love to add a generic FieldElement type to crypto-bigint, which similarly could always be in Montgomery form, but I was considering using const generics to represent the modulus (so field elements with a particular modulus are inherently type safe). Unforutnately that requires const generic features (valtrees) which haven't been implemented yet. Using const generics for this could also select optimized algorithms based on properties of the modulus at compile time, which would hypothetically provide efficiency gains.

We've considered porting over @cronokirby's implementation of modexp using Montgomery multiplication here: https://github.com/cronokirby/saferith/blob/08ff755fd8f7e060d9756857368435c53540d83b/num.go#L1361

...but I'd agree there's a case to be made for using a Barrett reduction instead in the event the inputs and outputs are all in canonical form.

[haslersn]

I was considering using const generics to represent the modulus

That's also what I'm doing in my project.

Unforutnately that requires const generic features (valtrees)

For what exactly do you need them? I'm on stable rustc 1.60.0 and do it like this:

pub trait ResidueParameters<const L: usize>: PartialEq + Debug {
    const MODULUS: Option<UInt<L>>;
}

#[derive(PartialEq)]
pub struct Residue<P, const L: usize>
where
    P: ResidueParameters<L>,
{
    repr: UInt<L>,
    phantom: PhantomData<P>,
}

I call it Residue instead of FieldElement, because the modulus doesn't need to be prime, so it's not necessarily a field. A modulus of None represents UInt::<L>::MAX + 1 where the native wrapping of the UInt type is used.

[tarcieri]

There's various ways to work within the limits of what's available on stable now.

For what exactly do you need them?

That works but is a bit clunky as you have to crate a ZST and impl ResidueParameters for it, versus just being able to pass the modulus as a const generic parameter:

pub struct Residue<const LIMBS: usize, const MODULUS: UInt<LIMBS>> { ... }

This will be possible after valtrees are implemented.

[tarcieri]

I think for starters we can implement MulMod (with breaking changes) using a Barrett reduction, and then circle back on FieldElement/Residue when adt_const_params are stable.

[ycscaly]

Now that it seems that valtrees have been implemented, where is this standing?

[ycscaly]

Also, can't the *Mod (esp. MulMod) traits be implemented with DynResidue ?

And why isn't there a PowMod trait? There is a pow() function for DynResidue.

[tarcieri]

Now that it seems that rust-lang/rust#95174, where is this standing?

As that issue notes, implementing valtrees is step 1 of 5. We target stable Rust, so we need all of those steps complete to make use of the feature.

Also, can't the *Mod (esp. MulMod) traits be implemented with DynResidue ?

All *Residue ops are definitionally modular, except the rhs is stored in self, so it doesn't match the signature of the trait.

And why isn't there a PowMod trait? There is a pow() function for DynResidue.

That is a notable API gap in the traits.

[ycscaly]

Now that it seems that rust-lang/rust#95174, where is this standing?

As that issue notes, implementing valtrees is step 1 of 5. We target stable Rust, so we need all of those steps complete to make use of the feature.

It seems that they also closed the issue after this step, and from my understanding that's because what has been implemented should suffice at least partially?

Also, can't the *Mod (esp. MulMod) traits be implemented with DynResidue ?

All *Residue ops are definitionally modular, except the rhs is stored in self, so it doesn't match the signature of the trait.

I'm not sure I understand what "rhs is stored in self" means. The signature is that a Uint gets an rhs of the same type, and a modulo of the same type and returns the same type right?

So if I:

1. create a DynResidueParams from p, use that to create a DynResidue of both self and rhs, add them, and then retrieve() and return the result - why wouldn't this match the signature of the trait ?

And why isn't there a PowMod trait? There is a pow() function for DynResidue.

That is a notable API gap in the traits.

Can't such an API be easily added?
Should I open a new issue for that?

[tarcieri]

It seems that they also closed the issue after this step

Huh? rust-lang/rust#95174 is still open and only the first checkbox of 5 is checked.

Though the feature exists on nightly that doesn't help us, because we target stable.

why wouldn't this match the signature of the trait ?

Because the modulus is stored in self, as opposed to being an explicit rhs parameter, which is what the trait expects.

Unless you're proposing there's a second modulus, which doesn't make sense to me?

Can't such an API be easily added?
Should I open a new issue for that?

Yes