[Cryptography] Photon beam splitters for "true" random number generation ?

[Peter Todd]

On Tue, Dec 29, 2015 at 05:54:03AM -0700, John Denker wrote:
> On 12/28/2015 11:30 PM, Jerry Leichter wrote:
> > I wonder about the [flash memory] physics here.  Can a block go bad
> > in such a way that it can be read but can't be erased?  (The
> > practical significance of such a failure mode - assuming it's
> > unlikely - is likely of little importance; I'm just "wondering out
> > loud".)
> 
> 1) Yes, such a failure is verrry unlikely.  It's getting into tin-foil
> hat territory.  It would cost the adversary a billion dollars per bit,
> on average, to get information this way.

That's failure mode happens all the time, on multiple levels. Heck, I've
personally seen a flash chip fail in that way! (PIC uC that I damaged
somehow, possibly static?)

You have to remember that flash cells usually required a voltage above
VCC to erase the cells; flash chips have relatively complex and fragile
charge pumps (usually w/ on-chip capactitors) that generate the
relatively high voltages required to erase the flash cells. Those charge
pumps can fail in a multitude of ways, with the result being that one or
more blocks can be read, but can't be erased. (usually all blocks, as
there's usually a single charge pump for the entire chip)

Another way this failure can happen is in firmware: flash chip firmware
notices that some cells aren't able to be reliably rewritten (or soon
will be) and goes into read-only mode to preserve user data.

Either way, I'm sure an adversary could find a whole variety of ways to
artificially induce read-but-not-write faults in a flash chip. (or for
that matter, an EEPROM)

-- 
'peter'[:-1]@petertodd.org
0000000000000000021ea73ed7003fbdb491eb7bd46f53b759d5adc0daf369fb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20151229/7c805b62/attachment.sig>