[Mono-list] RSA.Create() - major performance issues
sebastien.pouliot at gmail.com
Fri Apr 7 08:20:12 EDT 2006
On Fri, 2006-04-07 at 09:33 +0200, Hellan.Kim KHE wrote:
> I'm trying to create a component that should be used in a
> webapplication. It involves parsing of PKCS#12/PKCS#7 and creating
> signed/encrypted PKCS#7.
> It works fine, except the performance is really, really bad.
> Some places in the code I have lines like this:
> RSA signKey = RSA.Create();
> signKey.FromXmlString( ..... );
> I know the same is true for a lot of the Mono code.
> I never generate any keys, as they are all loaded from files/strings.
> However, RSA.Create() always generates a keypair which has a huge impact
> on performance.
Well we're missing critical pieces of information from your email.
Are you running your code under Mono (and if so which version, OS...) ?
Or are you running your code under the MS runtime (again version, OS...)
using Mono.Security.dll ?
As I know the (or a similar) problem I guess you are in the later case.
> Is there no way to just create an empty RSA object ready for loading a
> key into?
The design of the Fx cryptography is generally nice but (for some known
and unknown reasons):
(a) it is like half implemented, e.g. the RSA versus
RSACryptoServiceProvider mismatch - it's hard to extend RSA (and
it was impossible to extend DSA before 2.0) and keep existing
(b) was not server-friendly, e.g. always generating a new key;
(c) other issues non related to this discussion ;-)
If you're running on the MS runtime the automatic key pair generation is
a "feature". Yes this problem was reported (prior to 1.0 release) and it
was judged "by design" (1).
The only way to "fix" the issue (MS runtime) is to use the
RSACryptoServiceProvider class with CspParameters. However by doing so
you lose the ability to change the default RSA implementation at
Now back in Mono-land. In order to be compatible with MS implementation
Mono shares some of the same limitations. However delaying the creation
of the key pair doesn't break compatibility (2), so Mono always delays
the creation of a new key pair unless it's really needed (by a call to
some methods). If it's not delayed then it's either:
(a) a bug (i.e. please fill a test case into bugzilla);
(b) you make a call to something that requires a key component
(before loading a key pair);
(1) Microsoft changed their mind in framework 2.0 and delayed the
creation of the key pair until needed (just like Mono did ;-)
(2) Unless your application is sensitive to when the CPU is being used
(rare case and, anyway, it's easy to simulate the original behavior).
So this leaves us to Mono.Security.dll. This assembly is a component of
Mono that is totally compatible with the MS runtime (i.e. it has no
dependency on Mono specific technologies).
However Mono.Security.dll doesn't (and won't) limit itself to design
issues of specific MS framework versions (unless compatibility is
concerned). Mono.Security.dll use (e.g. RSAManaged) and expose (by using
RSA) the fact that the RSA class can be extended by third party
If this isn't a bug (i.e. if the problem doesn't occur on Mono runtime)
then you have the choice to:
(a) updating to the Mono runtime ;-)
(b) updating to MS Fx 2.0;
(c) hack your own version of Mono.Security.dll (e.g. by rename
it, change the public key used...)
P.S. It would be helpful in the future to include more information about
your environment (e.g. Mono version, OS version, .NET execution
Sebastien Pouliot <sebastien at ximian.com>
More information about the Mono-list