You may be fooling yourself with your ID length of 128. On many platforms, the limiting factor is the size of the seed, which is often 32 bits.
If you are attempting to start an argument with me,
you failed. I agree with you.
This is where some very serious testing needs to be done
on
any solution where you are attempting to produce
unique keys of any sort. Especially where real
"randomness" is required. Hence why elsewhere
in this thread I make reference to using system entropy
as they do in PGP and GNUpg and other cryptographic
products.
In 25 years of programming I have yet to see a truly random
random number generator over a sufficiently large data
set without the use of some external influence on the
numbers being generated.
This of course gets back to the basic premise that using
time() and friends to produce the id may not be
very ideal even for the simplest of application.
However, I stand by my opinion that the degree of randomness you
need is part of the design criteria you need to develop
in your program specification and the criticality it has
in relationship to the program you are writing and the
data or transactions you are trying to protect. If I am
generating unique IDS for sessions dealing with a guest
book application (OK... so I'm exaggerating) then I am
not going to worry too much about how random the key
generation is. On the other hand if I am protecting
national security data where lives are on the line then
I am going to look to somebody like the NSA for guidance
as to what the "latest and greatest" crypto
algorithm is.
Peter L. Berghold -- Unix Professional
Peter at Berghold dot Net |
| |
Dog trainer, dog agility exhibitor, brewer of
fine Belgian style ales. Happiness is a warm, tired, contented dog curled up at your side and
a good Belgian ale in your chalice. |
