Mark S. Miller wrote:
> On Wed, Jul 31, 2013 at 8:35 AM, Brendan Eich <brendan at mozilla.com 
> <mailto:brendan at 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

Mark S. Miller wrote:

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

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