[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cryptography
Subject:    Re: [Cryptography] Duh, why aren't most embedded TRNGs designed this way?
From:       Jerry Leichter <leichter () lrw ! com>
Date:       2021-05-25 21:32:47
Message-ID: 04E020CC-83DE-4169-B42B-6A426AFAB996 () lrw ! com
[Download RAW message or body]

> Not disagreeing with the technical statements, just with a perceived attitude: \
> "probably the closest thing to a mathematical proof (albeit probabilistic IIRC)" 
> The proofs we remember from high school geometry were not supposed to involve \
> probability, but for me that was 67 years ago. There has been a lot of acceptance \
> since then that some proofs could only involve probability, something like "This \
> has at most 0.00009% probability of being wrong" with rigorous, traditional \
> mathematical, arguments, to back that up....
I'm not even sure what "proof" (in the mathematical sense) has to do with "true \
random number generators."

A TRNG is a *physical object*.  It exists out there in the real world.  Sure, we can \
make mathematical arguments based on the existence of a "random source," but the \
mathematics doesn't do us any good unless we can realize the system in physical form.

"Proofs" about physical objects are not like mathematical proofs.  The best you can \
hope for is reduction to some physical process - e.g., Johnson-Nyquist noise - for \
which we have a great deal of evidence about the world and the laws that govern it to \
tell us it really is random.  But even then "Johnson-Nyquist noise" is an idealized \
description of what you would measure under certain conditions.  Any physical \
realization won't exactly match that description.  The idealized description, for \
example, assumes away interaction with external electromagnetic fields; the physical \
realization has to *build* a way to either avoid or negate that interaction or your \
reduction is gone.  And, of course, once you have the noise you need to turn it into \
a bit stream - again using real-world, physical, not idealized parts.

So in the end, "proof" is the least of your problems.  It's good engineering all the \
way down.  Oh, sure, if you do all the good engineering and then feed in a source \
that isn't random to begin with, you've wasted your time.  But that's just one small \
part.

And perhaps you could even do without the physical randomness.  Physical objects have \
inherent variations that are hard to predict or even measure.  Run the output of very \
high precision measurements through many steps of a chaotic process and the result \
won't be random, but it will be unpredictable to anyone who can't see as much of the \
initial state as the system itself can.  There is perhaps something deeply \
unsatisfying here, but in fact it's a direct response to Von Neuman's comment about \
living in a state of sin when generating random numbers by a deterministic process:  \
In fact, chaotic systems tell us that determinism and predictability are not quite \
the same thing in a world where inputs may not, even in principle, be exactly \
reproducible.

As has been commented, nothing in at least classical physics, or physical \
descriptions as such, talks about information leakage.  You can have a perfect random \
number generator that leaks every bit it generates, and the proof of "randomness," \
such as it might be, will be just fine.  But the resulting system is pointless.

Now QM does give you a way to say that some information inherently can't leak - or at \
least can't leak undetectably.  But how much that helps - when the goal is to deliver \
a sequence of *classical* random bits - is not at all clear.  Not much, most likely.  \
This makes some sense for quantum communication protocols - but those assume (and \
really there's no way of avoiding the assumption) that the "red" rooms at both ends - \
                which handle the decrypted data - never leak anything.
                                                        -- Jerry

_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
https://www.metzdowd.com/mailman/listinfo/cryptography


[prev in list] [next in list] [prev in thread] [next in thread]