RE: UUIDs in 2.0
> From: dean gaudet [mailto:[EMAIL PROTECTED]] > 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
RE: UUIDs in 2.0
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
> From: dean gaudet [mailto:[EMAIL PROTECTED]] > 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
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
> From: dean gaudet [mailto:[EMAIL PROTECTED]] > 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
On Fri, Sep 14, 2001 at 08:35:45AM +0200, Sander Striker wrote: > > From: dean gaudet [mailto:[EMAIL PROTECTED]] > > 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
> From: Greg Stein [mailto:[EMAIL PROTECTED]] > 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
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 [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
