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
Without them as part of the key object we need to compute them whenever we send keys to any of our current backends. Slow. (How slow?) Smells a bit like doing actual crypto ourselves.
If they're only generated when an RSA private key is instantiated, I don't think it's very slow; certainly not slower than generation of p and q themselves.
code to generate them is just (assuming an implementation of mod_mul_inv)
defmod_mul_inv(e, m):
""" Modular Multiplicative Inverse. return the value x such that (x*e) mod m == 1 """x1, y1, x2, y2=1, 0, 0, 1a, b=e, mwhileb>0:
q, r=divmod(a, b)
xn, yn=x1-q*x2, y1-q*y2a, b, x1, y1, x2, y2=b, r, x2, y2, xn, ynreturnx1%m
Per discussion in IRC I support adding these values as required parameters to the constructor. We can loosen this restriction in the future if we decide computing these values in Python is permissible/desirable.
Activity
Ivoz commentedon Feb 7, 2014
If they're only generated when an RSA private key is instantiated, I don't think it's very slow; certainly not slower than generation of
pandqthemselves.code to generate them is just (assuming an implementation of
mod_mul_inv)public commentedon Feb 7, 2014
Caching them on the private key object ourselves is indeed an option too. We need some benchmarks :)
reaperhulk commentedon Feb 8, 2014
Per discussion in IRC I support adding these values as required parameters to the constructor. We can loosen this restriction in the future if we decide computing these values in Python is permissible/desirable.