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

Dan Lewis dihlewis@yahoo.co.uk
Wed, 6 Feb 2002 11:37:32 +0000 (GMT)

Hi Duco,

Here's a link to the Leach draft. It never actually made it to being an RFC,
but I'm pretty sure that MS uses it for their GUIDs. You might want to check
that the numbers that come out of these algorithms look like the ones that come
out of MS .NET's GUID generator. It's pretty important that the same mapping is
used on all .NET machines and implementations, lest GUIDs become ... well, GIDs



 --- Duco Fijma <duco@lorentz.xs4all.nl> wrote: > 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
> _______________________________________________
> Mono-list maillist  -  Mono-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list 

Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts