--- Tim Reilly <[EMAIL PROTECTED]> 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 > 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".
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 http://en.wikipedia.org/wiki/Cryptographically_secure_pseudo-random_number_generator 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.) Yes. > 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 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. > 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. Phil > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________ Do you Yahoo!? Yahoo! Search - Find what you’re looking for faster http://search.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
