domenic at domenicdenicola.com (2013-08-02T20:48:12.244Z)
On Wed, Jul 31, 2013 at 8:35 AM, Brendan Eich <brendan at mozilla.com> wrote: > 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. 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.) > 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.
On Wed, Jul 31, 2013 at 8:35 AM, Brendan Eich <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. 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.) > > 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. > > > /be > -- Cheers, --MarkM -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130731/484fe464/attachment.html>