commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Reilly" <tim.rei...@consultant.com>
Subject RE: [id] UUID update
Date Fri, 05 Mar 2004 02:04:45 GMT
Hi Phil,

> Why, btw, did you think that we
> needed to use SecureRandom?  Is there any expectation in the spec
> that the
> random data will be cryptographically secure?

Quoting http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-02.txt
=============================================
4.5 Node IDs that do not identify the host

   This section describes how to generate a version 1 UUID if an IEEE
   802 address is not available, or its use is not desired.

   One approach is to contact the IEEE and get a separate block of
   addresses. At the time of writing, the application could be found at
   [6], and the cost was US$550.

   A better solution is to obtain a 47-bit cryptographic quality random
   number, and use it as the low 47 bits of the node ID, with the most
=============================================

I took the last paragraph to mean use SecureRandom. I also took for granted
that SecureRandom is "more" random than Random but haven't found
authoritative advice on that, it seems to be true or well believed? Anyone
know of documentation on the issue? The spec emphasizes the term "high
quality random".

As far as I understand everything in the specification concerning version
1 - the only real guarantee that the id will be *universally* unique is when
using the MAC address since it's from a central authority (and time shifting
backwards is still an issue even when a Mac is used but that the clock
sequence will deal with it if the generator does the time check and has
stateful information to know to change the sequence. I won't mention that
some NIC manufactures may have recycled Mac addresses according some posts I
saw also failures in the state persistence are possible.)
Using alterative node identifiers should be done in a way to make it
highly/extremely unlikely of a duplicate, but still the
potential/probability (though small) exists that different system generate
the same node, time, and clock sequence. It also depends on usage,
duplicates may be generated in systems that never interact so the
probability of duplicates within a group system actors is really what we
care about in reality (usually I guess.)

I should mention that a security concern was raised about using the MAC
address, when it will be exposed to other/outside systems. One side of the
security concern is around privacy (the uuid can give away a time and a PC.)
The other security issue I assume is if you've setup some sort of inbound
firewall rules based on MAC addresses or other reasons not to publish your
MAC's? I believe uuid.so and win32 CoCreateGUID both now generate version 4
uuid's for that reason. Of course, the reality is that the version and
implementation someone chooses should be guided by their requirements and
how they are using it (between trusted secure/trusted systems or not.)

Sorry for going on and on .. in answering a simple question ..took the
opportunity to share some of the research I'd got on the topic. Should and
probably needs to be in the documentation.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message