You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by dean gaudet <de...@arctic.org> on 2001/09/14 07:57:20 UTC
UUIDs in 2.0
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
RE: UUIDs in 2.0
Posted by Sander Striker <st...@apache.org>.
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: 14 September 2001 13:41
> Sander: you should have read the code before posting. The reference to the
> draft is right in the code.
>
Yeah, sorry about that. Too much things going on here at
the same time. Should have better kept my mouth shut. Again, sorry
for the clutter.
Sander
Re: UUIDs in 2.0
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Sep 14, 2001 at 08:35:45AM +0200, Sander Striker wrote:
> > From: dean gaudet [mailto:dean@arctic.org]
> > Sent: 14 September 2001 07:57
>
> > 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.
Standard format.
Within the source file, there is a reference to the Internet Draft for this
stuff: http://www.webdav.org/specs/draft-leach-uuids-guids-01.txt
See section 3.5 for the format.
> I believe uuids are modelled after dcerpc uuids. There is a Paul Leach
> draft on uuids floating around on the net. I would appreciate it if this
> could stay, it would benefit other projects aswell.
Sander: you should have read the code before posting. The reference to the
draft is right in the code.
> > - 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())
Uniform randomness. MD5 (and SHA-1) are very effective hashing functions.
Thus, for a given input, the resulting bits are uniformly random.
> > - "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".
However you want to phrase it. :-) I considered it more secure, but yah: it
is merely obscurity. And then there is the real nasty bit about figuring out
a MAC address :-)
> Yes, I would like to see the MAC addr implementation aswell. This is
> optional though.
Non-portable, and not required. The draft is quite explicit about options
for not using a 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.
Section 4 explicit discusses using various input bits and then hashing them
with MD5 or SHA1. So yes... it *is* Good Enough.
The situation is that we aren't trying for crypto strength, we're simply
trying for randomness in the hope that our random result won't match anybody
else's random result. No crypto needed there.
The spec does say that crypto quality is best, but definitely not required.
> The uuid draft states a truly random source of data should be used.
> Crypto quality.
No. See section 4.
> > - 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).
It probably shouldn't. Good point.
> > - get_current_time() is not thread safe
As noted in the code, yes.
>...
> > 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.
The thread safety and the srand() thing. The code could also use some
clarification and simplification. It is still a bit weirdly organized,
because of its way-back origin in the sample implementation from the draft.
Re: the size: you have the raw 16 bytes available. You could do a base64
encoding yourself, if you wanted to. But the provided functions will just
give you the standard format. *shrug*
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: UUIDs in 2.0
Posted by Ryan Bloom <rb...@covalent.net>.
On Friday 14 September 2001 02:57 am, dean gaudet wrote:
> On Fri, 14 Sep 2001, Sander Striker wrote:
> > I believe uuids are modelled after dcerpc uuids. There is a Paul Leach
> > draft on uuids floating around on the net. I would appreciate it if this
> > could stay, it would benefit other projects aswell.
>
> i'm not arguing to get rid of uuids, i realise they're in widespread use.
> i don't have to like them though :)
>
> > > - get_current_time() is not thread safe
> >
> > Use the apr equivalent?
>
> the code i'm referring to is in apr, and it's not thread-safe.
I believe Sander meant that we should re-write that code to rely on
the thread-safe APR time routines instead of the ones currently in that
function.
Ryan
______________________________________________________________
Ryan Bloom rbb@apache.org
Covalent Technologies rbb@covalent.net
--------------------------------------------------------------
RE: UUIDs in 2.0
Posted by Sander Striker <st...@apache.org>.
> From: dean gaudet [mailto:dean@arctic.org]
> Sent: 14 September 2001 12:45
> On Fri, 14 Sep 2001, Sander Striker wrote:
>
> > Isn't there an apr_get_current_time() that is thread safe?
> > apr_time_now()?
>
> that's not the point. i'm guessing you haven't read the code i'm
> referring to.
>
> -dean
Did now :)
Ok, it seems like most of the reference implementation ideas
have been duplicated. The get_current_time function is indeed
not thread safe... Hmmm, wrapping those statics in mutexes is
a major slowdown...
Ok, dean, suggestions? :)
Sander
RE: UUIDs in 2.0
Posted by dean gaudet <de...@arctic.org>.
On Fri, 14 Sep 2001, Sander Striker wrote:
> Isn't there an apr_get_current_time() that is thread safe?
> apr_time_now()?
that's not the point. i'm guessing you haven't read the code i'm
referring to.
-dean
RE: UUIDs in 2.0
Posted by Sander Striker <st...@apache.org>.
> From: dean gaudet [mailto:dean@arctic.org]
> Sent: 14 September 2001 11:58
> On Fri, 14 Sep 2001, Sander Striker wrote:
>
> > I believe uuids are modelled after dcerpc uuids. There is a Paul Leach
> > draft on uuids floating around on the net. I would appreciate
> it if this
> > could stay, it would benefit other projects aswell.
>
> i'm not arguing to get rid of uuids, i realise they're in widespread use.
> i don't have to like them though :)
I wasn't implying you were. You were commenting on the format of
the uuids, and that's what I wanted to keep the same.
> > > - get_current_time() is not thread safe
> >
> > Use the apr equivalent?
>
> the code i'm referring to is in apr, and it's not thread-safe.
Isn't there an apr_get_current_time() that is thread safe?
apr_time_now()?
> -dean
Sander
RE: UUIDs in 2.0
Posted by dean gaudet <de...@arctic.org>.
On Fri, 14 Sep 2001, Sander Striker wrote:
> I believe uuids are modelled after dcerpc uuids. There is a Paul Leach
> draft on uuids floating around on the net. I would appreciate it if this
> could stay, it would benefit other projects aswell.
i'm not arguing to get rid of uuids, i realise they're in widespread use.
i don't have to like them though :)
> > - get_current_time() is not thread safe
>
> Use the apr equivalent?
the code i'm referring to is in apr, and it's not thread-safe.
-dean
RE: UUIDs in 2.0
Posted by Sander Striker <st...@apache.org>.
> From: dean gaudet [mailto:dean@arctic.org]
> Sent: 14 September 2001 07:57
> 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 believe uuids are modelled after dcerpc uuids. There is a Paul Leach
draft on uuids floating around on the net. I would appreciate it if this
could stay, it would benefit other projects aswell.
> - 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".
Yes, I would like to see the MAC addr implementation aswell. This is
optional though.
> - /* 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.
The uuid draft states a truly random source of data should be used.
Crypto quality.
> - 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
Use the apr equivalent?
> 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
Sander