Hi, 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. 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. 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. Regards, Kim -----Oprindelig meddelelse----- Fra: Sebastien Pouliot [mailto:[EMAIL PROTECTED] Sendt: 7. april 2006 14:20 Til: Hellan.Kim KHE Cc: mono-list@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 <[EMAIL PROTECTED]> Blog: http://pages.infinit.net/ctech/ _______________________________________________________________________________________ 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. _______________________________________________ Mono-list maillist - Mono-list@lists.ximian.com http://lists.ximian.com/mailman/listinfo/mono-list