[Mono-list] RNG, Cryptography and Philosophy

[Andrew Birkett]

On Sun, 2002-10-06 at 03:11, Sebastien Pouliot wrote:
> Question 1: Where the code for the RNG ?

Look in configure.in and mono/metadata/rand.c.  There are
implementations of S.S.C.RNGCryptoServiceProvider.GetBytes and
GetNonZeroBytes.  These get wired up in the runtime in
metadata/icall.c.  Finally, in mcs/class/.../RNGServiceProvider.cs,
these two methods are marked as InternalCalls.  The other methods aren't
done, but GetBytes and GetNonZeroBytes should work.

> Question 2: How should this platform specific code be integrated in Mono ?

I think it's been suggested that in these cases we maintain a
FooLinux.cs and FooWindows.cs, both of which contain an implementation
of class Foo and pick the appropriate one at compile time.  

But if we start doing that, you won't be able to build
corlib.dll/System.dll/etc on one platform and then copy it to another.

> Right now there seems to be a little confusion in the class library about
> <class>Managed and <class>CryptoServiceProvider. 

I think this was a bad design decision by MS.  If it was only possible
create crypto objects through a factory class (ie. CryptoConfig), then
it wouldn't matter what these classes were called.  However, in .net it
is possible to directly instantiate the crypto classes, and so user code
can contain references to these class names.  Why should user code care
if they are calling a managed implementation or a wrapped version of a
system service?

Currently, I have been implementing the algorithms as C# managed code
regardless of whether they are named <class>CryptoServiceProvider or
<class>Managed.  This means they will work on all platforms supported by
mono, and user code which directly instantiates (say,
RC2CryptoServiceProvider) will still work as expected.

> ... RSA/DSA classes because they store their private key in
> CAPI containers (meaning that compatibility will required these classes to
> use CryptoAPI).

Ah, right ... RSACryptoServiceProvider.PersistKeyInCsp.  That's a
problem.  Don't MS ship a version of Rotor which runs on BSD?  How can
they support methods like this under BSD?  

Andrew