[Mono-list] Needed: randomness for System.Guid.NewGuid.

[Duco Fijma]

Currently, I'm implementing the System.Guid class. There is a single
method left to be left implemented: "Guid.NewGuid", which generates new 
"random"  Guids.

When I voluntered for the System.Guid class some time ago, Miguel wrote:

>For some bits of System.Guid maybe you will want to use an
>`internalcall' (we can implement this for you) to retrieve things like
>the ethernet address.
>
>Let me know what do you need, and we will implement.
>
>Miguel.

Well, here I am :-). I have no real experience accessing the "underlying
metal" in Mono/C#, so I would like to share some thoughts on the
strategy to follow when generating Guids and the way to access the bits
of randomness needed.

I had in mind the following strategy for implementing Guid's:
 
- When a network adapter is present, its hardware-address is used to
provide for the last 6 bytes of the GUID.
- When "real" random numbers are available (such as "/dev/urandom" on
Linux), these are used to fill the (remaining) bytes and we are done.
- If "just" pseudo random numbers are available, the (remaining) bytes
of the GUID are populated using a this pseudo random number generator in
combination with a clock. If available, some high-resolution clock is
used for this purpose.

The HW-address has to be made available via some InternalCall, or am I 
missing the point here and should I be able to retrieve this via
"System.Net.Sockets" in some way?

Access to high-quality random numbers could be integrated into
System.Random. Alternatively, we could choose to leave System.Random a
pseudo random number generator (like the Microsoft class library
documentation suggests) and let System.Guid access a "/dev/urandom"-like
device via some InteralCall or via direct file access of "/dev/urandom".
The latter obviously won't work under Windows, I have no idea whether an
alternative is available under that OS. I think I would prefer 
platform-specific things like this to be hidden behind an InternalCall.

For the clocks, something likewise holds. We could choose to "guarantee"
that System.DateTime has a resolution of 1ms or better (Microsoft's
implementation does NOT make such a guarantee) or to have some
alternative access (InternallCall?) to a high resultion clock.

Any thoughts? How will we combine efforts to implement the bits needed?

Regards,

Duco