RSA very slow, takes 11ms in release
Hello, I noticed that RSA key generation takes a long time, Like the README says release build do reduce the time, But 11ms for a 1024 Key is still a lot. I would love if there where some efforts going on to reduce generation time
When #394 lands we will switch to crypto-primes for key generation.
I would expect that to be faster but haven't benchmarked myself yet.
maybe related: https://github.com/RustCrypto/RSA/issues/29 (cannot say much otherwise, only remembered that old issue i also ran into that time :)
The current crypto-primes branch has a rough slow down of 2x last time I benchmarked, see the PR for a description of why
The current crypto-primes branch has a rough slow down of 2x last time I benchmarked, see the PR for a description of why
I don't see the Slower benchmarks, In the PR description are only a bunch of checkboxes. I also wonder what the point of this PR is when it brings a 2 times slow down
I also wonder what the point of this PR is when it comes 2 times slower
Security: https://github.com/RustCrypto/RSA/issues/19
@dignifiedquire they've recently added a number of improvements including parallel prime generation which haven't made it into a release yet.
Also, this seems relevant https://github.com/entropyxyz/crypto-primes/issues/61
Glad to hear that, the slowdown I was referring to was not key generation but signing & verification operations
@tarcieri, relevant in what way? We're thinking now in what way it should be exposed, so it's useful to know potential use cases.
@fjarri I was curious if it could be used to ensure certain properties of the generated primes, like non-adjacency of p and q, and ensuring the high bits are set so the bit lengths of the primes, when added, are always the intended key size
like non-adjacency of p and q,
That's probably best ensured by just starting the search from random positions for either?
and ensuring the high bits are set so the bit lengths of the primes, when added, are always the intended key size
This is already the case by default. Perhaps it should be stated clearly in the docs.
This issue appears to be a dup of #144