Ring: Replace the use of `BN_rand_range` in RSA blinding with Rust code

[briansmith]

The Rust code logic in ring::ec::suite_b::private_key::generate_private_key should be factored out into something that both ring::ec::suite_b::private_key and RSA blinding can use.

With this, all of crypto/bn/random.c (BN_rand and BN_rand_range) can go away.

[djudd]

I'm going to try my hand at this. My C is rusty (no pun intended) and my experience with crypto programming is minimal, so apologies in advance if I don't make much useful progress. I'll try to report back if I get stuck and don't expect to submit a pull request.

Thanks for the cool project and the beginner-friendly issue tagging!

[djudd]

I have a question for @briansmith, about this code. Why do we convert bytes to limbs in this particular way? It appears that we break the bytes into limb-sized chunks, which we treat as internally big-endian, but as ordered little-endian externally.

This is causing two problems for my refactoring attempt. One is that it's inconsistent with BN_bin2bn, which I'd like to use in reimplementing BN_rand_range instead of reimplementing both. I could just write equivalent Rust code for initializing a BIGNUM, but a tougher issue is that it doesn't translate very well when you have a number of bytes that isn't a multiple of LIMB_BYTES, which is true when selecting randomly in some of the ranges we encounter with the RSA tests.

Is there any harm in changing this to use the simpler BN_bin2bn strategy? It doesn't _appear_ that it will matter, since the bytes are random and thrown away after generating this private key or blinding key. But I want to make sure there isn't some security implication I'm missing.

[briansmith]

I have a question for @briansmith, about this code. Why do we convert bytes to limbs in this particular way? It appears that we break the bytes into limb-sized chunks, which we treat as internally big-endian, but as ordered little-endian externally.

If so, then that code is wrong. It should be made to work like BN_bin2bn. Apparently I suck at endian conversion.

[briansmith]

If I understand the scope of this, this was done in #254. Please holler if I'm wrong.