You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After #246 and #365 are done, it should be straightforward to replace GFp_BN_mod_exp_mont_vartime. RSA signing and RSA verification are the only remaining operations that use BIGNUM. In particular, these will be the only two operations that use the heap. We would like to enable RSA signature verification in environemnts where there is no heap available too, so this is an important project.
We should write a new modular exponentiation function that always uses square-and-multiply, using/extending ring::rsa::bigint as needed. Note that verification doesn't need to be constant time.
Typically, the public exponent is 65537 (0x10001). Sometimes it is 3 (0b11). It is rarely any other value. Note that the typical exponents 0x10001 and 0b11 have hamming weight of 2. When the hamming weight is 2, the optimal algorithm is the simplest one: square and multiply.
Even if the exponent has a large hamming weight, the largest hamming weight possible is 33, because the RSA implementatoin already restricts the public exponent to a maximum of 33 bits. This maximum was also contributed to BoringSSL so that Google Chrome could field-test that a 33-bit maximum is web-compatible.
BN_window_bits_for_exponent_size already uses the basic square-and-multiply algorithm for exponents that are less than 24 bits; i.e. almost all the time. It only uses window-based exponentiation for exponents of 24 bits or more, and even then it only uses 3-bit windows.
Thus, the difference in performance in the best case should be minimal, and the difference in the worst case, which is extremely rare, will be only a little bit worse.
We can then remove BN_window_bits_for_exponent_size .
It's probably better to do this after #246 and #365 to avoid Rust -> C -> Rust call stacks that would require ugly temporary FFI code.
The text was updated successfully, but these errors were encountered:
There are two parts to this: Using the simpler algorithm, and making the implementation of the simpler algorithm work without the heap. I've already done the first part in a private branch.
[Split off from #246.]
After #246 and #365 are done, it should be straightforward to replace
GFp_BN_mod_exp_mont_vartime
. RSA signing and RSA verification are the only remaining operations that use BIGNUM. In particular, these will be the only two operations that use the heap. We would like to enable RSA signature verification in environemnts where there is no heap available too, so this is an important project.We should write a new modular exponentiation function that always uses square-and-multiply, using/extending
ring::rsa::bigint
as needed. Note that verification doesn't need to be constant time.Typically, the public exponent is 65537 (0x10001). Sometimes it is 3 (0b11). It is rarely any other value. Note that the typical exponents 0x10001 and 0b11 have hamming weight of 2. When the hamming weight is 2, the optimal algorithm is the simplest one: square and multiply.
Even if the exponent has a large hamming weight, the largest hamming weight possible is 33, because the RSA implementatoin already restricts the public exponent to a maximum of 33 bits. This maximum was also contributed to BoringSSL so that Google Chrome could field-test that a 33-bit maximum is web-compatible.
BN_window_bits_for_exponent_size already uses the basic square-and-multiply algorithm for exponents that are less than 24 bits; i.e. almost all the time. It only uses window-based exponentiation for exponents of 24 bits or more, and even then it only uses 3-bit windows.
Thus, the difference in performance in the best case should be minimal, and the difference in the worst case, which is extremely rare, will be only a little bit worse.
We can then remove
BN_window_bits_for_exponent_size
.It's probably better to do this after #246 and #365 to avoid Rust -> C -> Rust call stacks that would require ugly temporary FFI code.
The text was updated successfully, but these errors were encountered: