[Mono-list] RNG, Cryptography and Philosophy

[Sebastien Pouliot]

> The RNG code works on Linux, should work on BSDs, maybe Solaris, and
> won't work on Win32.

Question 1: Where the code for the RNG ?
The source of both RandomNumberGenerator.cs and RNGCryptoServiceProvider
doesn't return anything.
Are the random function hidden somewhere in the runtime (an not yet called
by the class library) ?

> I'm still a tad confused by the CryptAPI for
> windows.  If you know how to use it to get strong random numbers, have
> at it...

I've done a quick helper class for CryptoAPI and I can generate chaotic
random at will ;-).
However this is Windows-specific code (as it calls advapi32.dll to access
CryptoAPI).

Question 2: How should this platform specific code be integrated in Mono ?
The helper class (CryptoAPIHelper.cs) and the updated
RNGCryptoServiceProvider.cs will ONLY work on Windows. I don't even have
tried it with Mono (on Windows) - but I will before committing anything on
the list.

Note: There's no rush to make a final decision on this as the helper class
will need to be updated to be used for other <class>CryptoServiceProvider
(like hash, symmetric and asymmetric algorithms).

Doing this I realized that I was about to do something "unconventional" (for
a lack of a better word) in the System.Security.Cryptography namespace. I
was about to limit a class to a specific platform - something that the MS
framework has, kind of, anticiped.

Right now there seems to be a little confusion in the class library about
<class>Managed and <class>CryptoServiceProvider. Mono seems to duplicate the
binary classes present in MS Framework. This is a good thing for
compatibility but by doing so we are breaking the philosophy about
<class>Managed and <class>CryptoServiceProvider.

MS philosophy is (or, from thousand miles east, at least seems to be):
- <class>Managed are classes implemented using 100% managed code (as all
Mono classes seems t be right now - at least before today);
- <class>CryptoServiceProvider are classes that link to an external source
for cryptography (ex: HSM, smartcards or other software library like
CryptoAPI).

IF (and this is an important if) we follow this philosophy this means that
all current classes (which are all 100% managed classes - and I'm really
happy about this) should all be named <class>Managed. The CryptoConfig can
then be modified to return the managed classes as default implementation (so
every "good behavied" application won't see any difference).

The problem is that many current applications (the "un-behavied" ones -
which, by my count, looks like 98%) are directly binding to
<class>CryptoServiceProvider classes (bypassing the CryptoConfig class). In
order to maintain compatibility with these applications (IMHO compatibility
is MUCH more important for Mono than philosophy) we should:

a.    On Windows platform:
        - implement all *CryptoServiceProvider using CryptoAPI. This is
REALLY important for RSA/DSA classes because they store their private key in
CAPI containers (meaning that compatibility will required these classes to
use CryptoAPI).

b.    On Linux (and other platforms):
        - create stubs for every <class>CryptoServiceProvider classes and
map them to the associated <class>Managed. This solution is to ensure
compatibility with software using <class>CryptoServiceProvider classes
directly.
        - later we could provide templates to implement external
cryptographic algorithms. I've experience using PKCS#11 devices and
libraries. So I could develop a PKCS#11 template. My only problem is that,
right now, I dont have any PKCS#11 device to test such a template :-(

The result of this "BIG IF" would be that Mono would have more cryptographic
class than MS (but no more algorithms - unless we want so). However this
wouldn't affect compatibility because:

1. All <class>CryptoServiceProvider would be available (linked to *Managed)
for existing compiled assemblies.
2. Normally "good" software (< 2% but, hopefully, improving) should use
CryptoConfig (or an algorithm base class) to locate an algorithm - which
would return the default implementation (*CryptoServiceProvider, *Managed).

This way both compatibility and philosophy are preserved. ;-)

Question 3:    Any thoughts about this ?

> Mark


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