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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
