SV: [Mono-list] RSA.Create() - major performance issues

Fri Apr 7 09:06:21 EDT 2006

Hello Kim,

On Fri, 2006-04-07 at 14:50 +0200, Hellan.Kim KHE wrote:
> Sorry about the missing information.
> My component is running on Microsoft Windows XP/2003 with .NET framework
> 1.1.
> I'm using the Mono.Security.dll version 1.0.5000.0.

[note: Mono.Security.dll assembly version are kept in sync with MS
version releases, as some Mono core assemblies depends on it. The "true"
version number of the assembly is the Mono version]

> 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
> object.

Thanks for the additional details (and for confirming my theory :)

> 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.

Yes, like most uses of RSA. In production code key generation is the
exception not the rule...

> So for my configuration are there any "easy" workarounds to avoid key
> generation (like the delayed key generation that you mention)?

I can only think about the one I mentioned earlier... you may want to
try Google on the problem (as many people have been affected by it, so
maybe someone found an alternative solution ?).

> If this MS design flaw is somehow handled in later versions of
> Mono.Security.dll, I have no problems upgrading.

Sadly there isn't a "correct" way to fix this and keep the extensibility
model (provided by using RSA) which also implies keeping binary
compatibility (for existing Mono.Security.dll users). Furthermore this
issue is "already" corrected in MS Fx 2.0 and doesn't affect Mono
(runtime) users.

> Regards,
> Kim
> 
> 
> 
> -----Oprindelig meddelelse-----
> 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
> 
> Hello Kim,
> 
> 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
>         code running;
>         
>         (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
> runtime.
> 
> 
> 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);
> 
> 
> Notes
> (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
> implementations.
> 
> 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
> platform...).
-- 
Sebastien Pouliot  <sebastien at ximian.com>
Blog: http://pages.infinit.net/ctech/