On 18-Jul-12 08:25, Saku Ytti wrote: > On (2012-07-18 09:10 -0400), [email protected] wrote: >> You want to roll in at some entropy by adding in the current date or >> something, so two "Joes' Burritos and Internet" in 2 different states don't >> generate the same value. There's a reason that 4193 recommends a 64bit >> timestamp and an EUI64. > I assume business ids are federal not state, as IRS is federal? Anyhow I'm > not saying 'this is how it should be done', I'm saying maybe there is way to > do this in a way which is verifiably random.
US EINs/SSNs, and various state-level ID numbers, are not random; given our problems with identity theft, they're not guaranteed to be unique, either. I assume the same is true for identification numbers in most other countries. > 64b timestamp and EUI64 make it non-verifiable. If you publish the numbers you used, then others can verify that those values are reasonable. I doubt anyone would sift through billions of reasonable timestamps combined with the thousands of EUI64s at their site just to find a result that was "memorable". And, if they did, who cares? It's not like it hurts me for them to do so--unless I'm dumb enough to do the same thing, happened to get the same result /and/ happened to merge with them--all of which are still unlikely events. S -- Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
smime.p7s
Description: S/MIME Cryptographic Signature
