commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject RE: [id] UUID update
Date Fri, 05 Mar 2004 02:42:36 GMT

--- Tim Reilly <> wrote:
> 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
> =============================================
> 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".

It all comes down to whether or not you care if a *sequence* of randomly
generated values is predictable. The default Random generator is not bad in
terms of dispersion (i.e., likelihood of collisions, number of matches
among bytes, etc.) but not "secure" in the sense that knowledge of previous
results has little or no value in predicting new values.  See
for a little more on this.   

> 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.)

SecureRandom offers no special advantage there. Two byte arrays generated
by a SecureRandom are no less likely to collide than a pair generated by a
Random (at least not significantly -- though the exact probablilities no
doubt differ, both will be remarkably close to expected binomial
probabilities in practice)
> 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 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.

This is an important issue. I have never viewed GUIDs as in any way
"secure."  As you point out, the MAC address is not at all secure. Maybe we
should support both "secure" and "non-secure" version 1 GUIDs. 

The comment below in Section 7 suggests, however, that there is no
expectation of cryptographic security, so I guess I would favor the
"non-secure" approach:

 Security Considerations

   Do not assume that UUIDs are hard to guess; they should not be used
   as capabilities, for example.

I would attribute the "cryptographic quality" reference in section 4 as
just referring to randomization.  Making the PRNG pluggable might be a good
compromise solution.

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message