Mark S. Miller wrote:
On Wed, Jul 31, 2013 at 8:35 AM, Brendan Eich <bren...@mozilla.com
<mailto:bren...@mozilla.com>> wrote:
Mark S. Miller wrote:
Don't ever use MAC addresses, dates, times, positions, etc, as
sources of uniqueness.
uuidgen implementations have used MAC addresses in the past, which
I believe led to a public collision.
What a collision resistant string? Use 128 bits of entropy.
You'll get an accidental collision of these with the same
rarity as you will for two unique symbols because of an
undetected memory error.
Wait, what? An "undetected memory error" meaning a GC bug where a
symbol is freed before it is dead and reincarnated as another
symbol? That is rare enough that I don't believe you (or anyone)
can say colliisions are as rare. We are arguing
quality-of-implementation here.
I'm not talking about the probability of a software bug. We all write
perfect software so the probability of such bugs is zero -- I agree.
Heh. My point was the probability of each bad thing (memory safety bug,
uuid collision) is probably higher than we think but I have no data.
No, I'm talking about the probability of an undetected hardware
failure, such as one caused by cosmic rays or other physical causes.
All digital hardware rests on analog hardware which rests on quantum
mechanical hardware. There ain't nothing else. Our digital hardware is
all built to keep the error rate below some threshold considered
acceptable. For any hardware we can afford, that error rate threshold
is also not violated by accidental collisions between randomly chosen
128 bit keys. (Unless we're worried about birthday effect collisions,
as perhaps we should be, in which case we should go to 256 bits of
entropy.)
A crypto-grade RBG should be enough, I agree.
Gathering entropy enough to make a UUID is work. A crypto module's
RBG should be up to it. Browsers have those, but we haven't yet
required any such thing in ECMA-262, and I expect some
implementations will be crypto-module-free and cheese out on the
quality (where they wouldn't ship unpatched memory safety bugs!).
This is worth a discussion: do we require an RBG with the right
quality in normative words in ES6?
A good point. We should indeed discuss the costs of adding this
requirement.
Ok. I think it's going to be a problem for "tiny" embeddings of ECMA-262
implementations (Japanese smart TVs? Maybe these are "legacy", the
"compact profile", even). We need to cast a wide net.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
