[Q]:Generate Unique ID's

[Tim Peters]

[Tim]
>> ... On the box I'm typing at right now (an 866 MHz Pentium III),
>> there's also that the Twister generates pseudo-random numbers much
>> faster from Python than the Intel HW RNG generates them from pure C
>> code -- monitoring thermal noise in a physical system is a
>> time-consuming process.

[Anton Vredegoor]
> Could you please give a pointer to the C-code you are using? I'm
> currently polishing up some code I posted a while ago and having a
> look at other implementations might be beneficial.

Sorry, I don't know anymore.  I already had the Intel Security Driver and
downloaded some arbitrary C wrapper via a google search.  This was an
experiment before the Twister was checked in, and I didn't have any other
use for the code.

> By the way, I believe the Intel HW RNG is implemented by the chipset
> on the MB and is not present in the Pentium processor chip itself.

Yes.  It shows up as the "Firmware Hub Device" if it's on your motherboard.

>> For most uses of RNGs, I'd much rather have the speed.  Note that HW
>> RNGs, and the software driving them, aren't immune to bugs either --
>> there's no escape from the general rule that an algorithm relying on
>> RNGs has to be verified by statistical testing, and having another
>> high-quality source of RNGs is helpful in that even if you intend to
>> use truly random bits in deployment.

> What comes below here is probably a philosophic point so take it with
> a grain of salt :-)
>
> Suppose you are trying to convince a club of bridge-players to use
> your bridge-dealing software. It probably would not matter to them if
> you knew which dealing is going to come next as long as they don't
> know you know.
>
> However, there's also a slight possibility that putting some photons
> in a straightjacket by deterministically fixing the order of all
> bridge dealings beforehand might degrade the number of possible paths
> the future can take.
>
> I wonder which Python zen applies here, "Refuse the temptation to
> guess" or perhaps "Practicality beats purity" ?

The latter for me.  If you're worried about the inconsequentially unikely,
then as Knuth points out, if you have a truly random source and suck random
bits out of it, every now and again you're going to get a billion zeroes in
a row.  Most applications of RNGs would be devastated by such an occurrence
(e.g., trying xor'ing a billion zeroes into plaintext as a means of
encryption).  OTOH, for most PRNGs it's possible to prove that will never
happen.  Excepting bugs, of course, and again the HW and SW going into
physical RNGs isn't immune to bugs either.