[Mono-list] RNG, Cryptography and Philosophy

[Sebastien Pouliot]

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

Thanks. I didn't look at the attributes.

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

We "could" (not a recommendation!) switch at runtime but this will get ugly
as Mono support more, and hopefully much more, operating systems.
But surely, we aren't the only one with this problem (I found something
about the Registry in the archive). So maybe this decision is already made ?

I never checked but is it possible that mscorlib.dll is the only one (or one
of few) mixing managed/unmanaged code ?

That would explain why the System.Security.Cryptography.X509Certificates is
splitted between corlib.dll and system.dll. This would be good news as only
(part of) a single dll would be system dependant.

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

I completly agree.

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

Well there are some reasons: like HSMs, smart cards, ... which can requires
special activation steps (authentication with PIN, passwords, biometry,
...). This is possible today (on Windows) using CSP, as they can show their
own user interface, unlike PKCS#11.

So it's reasonable that some software want to deal directly with a specific
class.
Anyway that access could have been made through CryptoConfig.

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

AFAIK there are no cryptographic classes in Rotor.

Another problem may be the RNG. It's much easier to get a good RNG from the
operating system than implementing one in a managed environment. Well the
pseudo-random algorithm isn't the problem - it's more getting a good seed
value to start it. Unless someone know a good seed source from the runtime ?

> Andrew

Sebastien Pouliot
Security Architect, Motus Technologies, http://www.motus.com/
work: spouliot@motus.com
home: spouliot@videotron.ca