Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Fri, 14 Sep 2001 04:40:35 -0700
From: Greg Stein <gstein@lyra.org>
To: dev@httpd.apache.org
Cc: dean@arctic.org
Subject: Re: UUIDs in 2.0
Message-ID: <20010914044034.B28748@lyra.org>
References: <Pine.LNX.4.33.0109132239460.5577-100000@twinlark.arctic.org>
 <JLEGKKNELMHCJPNMOKHOGEEGEJAA.striker@apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <JLEGKKNELMHCJPNMOKHOGEEGEJAA.striker@apache.org>;
 from striker@apache.org on Fri, Sep 14, 2001 at 08:35:45AM +0200

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/