[Mono-devel-list] Using RSA optimally with both Mono and MS .Net

Sebastien Pouliot sebastien.pouliot at gmail.com
Fri Jul 29 15:51:24 EDT 2005

Hello Thomas,

On Fri, 2005-29-07 at 13:07 -0400, Thomas Harning Jr. wrote:
> With Mono's implementation, it's really easy to use the RSA Crypto
> classes because it doesn't generate a key automatically on construction.

yes, this is done by default.

> I'm developing an application with Windows as a target, since ATM my
> family uses it and it currently has a large userbase.

I like the "currently" ;-)

> I've tried out using CspParameters to store a private key for reuse
> [though I don't particularly like how that key store works, I
> generally prefer storing it in a location I control].
> CspParams doesn't seem to offer any way to load up a public key.

AFAIK you should be able to import a public key in a container. However
IIRC there are some bugs related to re-using containers (e.g. the
container and the new key must have the same key length).

> Unless there's a good way to work around loading public keys into a
> Csp I see a few options:
> 1) Use Mono's managed RSA encryption.  However, I wonder how this
> compares to using the CryptoAPI for Microsoft.

Slower, but you probably won't notice it unless you do:
* a lot of RSA ops (which is generally a bad sign for most, non-server,
applications); or
* key generation;

> 2) Wrap a library like openssl for crypto.  [I might just do this to
> help out Mono and for performance optimization].

That would be nice and, if done correctly/completely, could be used by
most existing applications without any re-compilation.

> As an aside... does .Net 2.0 do the foolish automatic construction
> of an RSA key?

That was fixed a long time ago (probably even in the 1.2 preview). There
was no point to generate a new key each time you create an instance (as
was a performance killer for any server-based application).

>   Or perhaps does it offer a constructor that would
> accept RSAParameters 

I'm not aware of any new constructor.

> [pretty obtuse not to offer a constructor like
> that].

There are some good reasons for this but, sadly, they aren't consistent
everywhere in the Fx (so I can't be sure if this is by "good" or "bad"
design ;-).


More information about the Mono-devel-list mailing list