SV: [Mono-list] RSA.Create() - major performance issues
KHE at kmd.dk
Fri Apr 7 08:50:35 EDT 2006
Sorry about the missing information.
My component is running on Microsoft Windows XP/2003 with .NET framework
I'm using the Mono.Security.dll version 1.0.5000.0.
I'm using the System.Security.Cryptography.RSA class.
I don't think that there are any bugs in Mono, I could just see that you
do the same as I do by calling RSA.Create() and then load a key into the
I don't need to do anything "fancy" with the RSA key, I just need the
object to hold the imported key that I use for signing my PKCS#7.
So for my configuration are there any "easy" workarounds to avoid key
generation (like the delayed key generation that you mention)?
If this MS design flaw is somehow handled in later versions of
Mono.Security.dll, I have no problems upgrading.
Fra: Sebastien Pouliot [mailto:sebastien.pouliot at gmail.com]
Sendt: 7. april 2006 14:20
Til: Hellan.Kim KHE
Cc: mono-list at lists.ximian.com
Emne: Re: [Mono-list] RSA.Create() - major performance issues
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
> 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>
www.kmd.dk www.kundenet.kmd.dk www.eboks.dk www.civitas.dk www.netborger.dk www.organisator.dk
Hvis du har modtaget denne mail ved en fejl vil jeg gerne, at du informerer mig og sletter den.
KMD skaber it-services, der fremmer effektivitet hos det offentlige, erhvervslivet og borgerne.
If you received this e-mail by mistake, please notify me and delete it. Thank you.
Our mission is to enhance the efficiency of the public sector and improve its service of the general public.
More information about the Mono-list