Shorten widths of BoxedUints

[fjarri]

Fixes #490

• Bump crypto-bigint dependency to the current trunk.
• Use the width of a single prime instead of the full modulus where possible. Brings bench_rsa_2048_pkcsv1_decrypt to pre-crypto-bigint values.
• Add a check to RsaPrivateKey::from_components() to ensure consistency between the primes and the modulus.
• Remove zero padding limbs from the primes and the modulus in RsaPrivateKey::from_components().
• Add a check to rsa_decrypt() to ensure the bit precision of the ciphertext is the same as that of the modulus.

Notes:

• bench_rsa_2048_pkcsv1_sign_blinded can be restored to the original performance by using variable-time inversion in algorithms::rsa::blind() (as it was during num-bigint times), but it seems to me that the blinding factor must be kept secret, so we have to use the constant-time inversion. This leads to about 5x slowdown compared to pre-crypto-bigint performance.
• The changes in test vectors are due to Make random_bits_core platform independent crypto-bigint#781

Possible further improvements

• Keep precomputed values as Odd/NonZero as appropriate.
• If Division algorithms unification crypto-bigint#811 is fixed, resizing integers for the purposes of division can be avoided.

[tarcieri]

The r^(-1) mod n was variable-time before crypto-bigint; is that secure?

Everything was variable-time before crypto-bigint, and to my knowledge it's insecure. It would probably be best to make it constant time despite the performance hit.

Hopefully we'll get better performance after a migration to bingcd

[tarcieri]

• The new try_set_precision() may be a method in BoxedUint
• shorten/widen may need some fallible equivalents

So if I understand the goal of these, it's to prevent truncating the contents of a value, correct?

If so, adding them upstream seems fine. Perhaps they could be made constant-time?

[fjarri]

Everything was variable-time before crypto-bigint, and to my knowledge it's insecure. It would probably be best to make it constant time despite the performance hit.

That's unfortunate, it's like a 5x slowdown.

So if I understand the goal of these, it's to prevent truncating the contents of a value, correct?

Yep.

[tarcieri]

@fjarri do you want to try to upstream try_set_precision and e.g. try_shorten first, or merge this as-is and follow up on that later?

[fjarri]

Let me try it out, I'll see if I can distill some required functionality into general-use methods.

As for the inversion, I need to check if preparing the inverter in advance makes things any better.

[tarcieri]

It’s unlikely to impact performance aside from optimizing away a single allocation

[fjarri]

Converting to draft until we merge RustCrypto/crypto-bigint#809 in some form