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

[John Denker]

On 12/28/2015 07:14 PM, Tom Mitchell wrote:

> Metal layers are aluminum, copper and tungsten yet the quality of the
> transistors can be baked away at temps well below melting.  Diffusion
> requires precision so modest temp soak can disable the gates.

It is easy to put the flash chip beyond normal use ... but that
is not the same as being fully secure, because the attacker 
might use non-normal methods, including things like electron
microscopes.  The real question is how fast the electrons diffuse
out of the floating gates.

Note that when GCHQ wanted to destroy The Guardian's computers
they did not consider it sufficient to bake the circuits.  They
seems to have a pretty good idea of where bits might be hidden.
Reference:
  https://theintercept.com/2015/08/26/way-gchq-obliterated-guardians-laptops-revealed-intended/

On the other edge of the same sword, I mention yet again that 
baking is not very nice from a human-factors point of view.
 
> Pulling this back to crypto.
> Most USB memory keys contain vendor software
> to encrypt the content and drivers that allow the
> reading and writing.
> 
> Are any of these vendor solutions any good?

I have zero confidence in them.  People have recovered data
from supposedly-erased flash chips without much effort.
Reference:
   http://cseweb.ucsd.edu/~m3wei/assets/pdf/safe-paper.pdf
Quote:
  «Of the remaining seven, only four executed the “ERASE
  UNIT” command reliably.»

> I expect most are compromised so I format and repartition devices ASAP.

That's known to be not good enough.  The device could quite
plausibly have twice as much storage as you think it does,
and who knows what is lurking in the hidden half.

> What alternatives might there be to replace vendor tools?
> In some cases a user space driver can allow
> views when the OS anchored tools are difficult to trust.

Not sure what is the question there.  See previous references
to various open-firmware efforts.

> Virtual machines can be given raw access to devices.
> Is that access raw enough that VM hosted OS qualities
> apply?

Not sure what is the question there.  The problem is that 
modern flash chips are highly complex and highly variable.
"Generic" drivers cannot keep up.  For practical purposes,
you need the chip vendor to ship a suitable driver along
with the chip.  OTOH chip vendors have no clue about crypto.
One way out of the dilemma would be to have a sufficiently 
flexible driver license, either open source or a not-too-
nasty NDA, so that somebody competent can add the required
crypto-friendly features.

Some manufacturers (e.g. Micron) make nice noises about
supporting open-source efforts.

To answer a question that other people have been asking, one
can mitigate the turtles-all-the-way-down problem by using 
cut-and-choose.  You order a bunch of chips.  You tear down
some random subset, and verify that the gate layout and
firmware conform to specifications.  This, in conjunction
with sufficiently harsh penalties for noncompliance, provides
some modest level of confidence.
 
> Assertion(this may be true).  I believe, if a device was properly encrypted
> I do not care if all the blocks (spares, defects, spares) are out of my
> control?

That's called a hypothesis, or perhaps a question; not an 
assertion.

In any case, the answer depends on your threat model.  It
depends on what problem you're trying to solve.  If you are 
trying to build a one-time pad, as various people including
Henry Baker have suggested (with varying levels of seriousness)
encrypting it is nowhere near good enough.  It requires you
to trust the crypto, rather than trusting the intrinsic
one-time-pad properties.

There are other scenarios where it might OR MIGHT NOT be
good enough to encrypt the data and throw away the key.
First of all you have to trust the crypto, and secondly you
have to trust that the key has been thoroughly obliterated,
which just gets us back to the problem previously not solved.
Typically crypto changes the /magnitude/ of the problem by
protecting a big file with a small key ... but it does not
reduce the problem to zero.  Beware that if you screw this
up, you are giving the storm troopers a reason to beat the
key out of you.

Also, full-disk encryption imposes a cost in terms of access 
time and battery life.  For most applications it's worth the
cost, but not everybody is 100% happy with it.

Bottom line:  There are always going to be "some" things that 
need to be erased.