On Thu, 13 Sep 2001, Greg Stein wrote:
> Regarding APR's UUID solution: if you think it isn't "good enough", then I'd
> be interested in knowing. It collects a decent amount of see and then hashes
> it to get a "random" result. If there is more seed data that we could use,
> then we should.
i have several complaints about UUIDs really, and i wanted to research
more before posting (such as reading the justification of others for the
particular implementation in unix/getuuid.c), but maybe you can save me
the time:
- one is their text representation length... 36 characters long when 20
or so is sufficient.
- i don't understand md5 crypto enough to know the random properties of
taking only 6 characters of a rather longer md5 result. (see
get_random_info())
- "more secure because we don't pass out our MAC address" is security
through obscurity :) it's better to say "we don't want to portably figure
out our MAC address".
- /* crap. this isn't crypto quality, but it will be Good Enough */
uh huh. confidance inspiring. i hope the original UUID proposal says
it's ok to use not quite crypto quality numbers here.
- why should srand() be used in the middle of a library routine? that's
stealing the seed from the application -- people can't now generate
repeatable code (which is an important debugging tool).
- get_current_time() is not thread safe
i would say though that my single worst complaint is the size of the
things, i rather like the base64 encoding over base16. but i understand
that these are somewhat of a standard now? oh well. the thread safe
thing should be fixed.
-dean
