Dear cryptography enthusiasts!
Glad to see a mailing list still in operations for applied cryptography.
In my ever ensuing quest for proper implementation of applied
cryptographic techniques, I spent some time on the source of random
secrets in a security system. I also reviewed the "best practice" for
casino and gambling systems, including on-line (conformance to standards
is important for player's confidence that the game is fair, for whatever
"conformance" and "standards" means in the various segments -- or
jurisdictions -- in this industry).
With the recent security incident where a private signature key has been
trivially recovered because the signature system wrongly re-used a
random secret, we get a reminder that random secret data
*throughout*its*life*cycle* need to be handled with caution.
So, here are a few highlights of my recent findings. I found that too
many notions deserved a description of rationales, and hence a
draft-in-progress document is just stalled.
STANDARDIZATION
Only NIST (with the help of NSA and participants in a circa 2004
symposium) advanced the true random source standardization effort, with
the main outcome being NIST SP-800-90. Neither the financial industry
(ANSI) nor the European digital signature got any noticeable momentum on
true random source standardization.
Even with the NIST outcome, the technical quality of the standard is
questionable. There are various meanings for "entropy" in the document
(and its references), and even when a proper definition is intended, its
use does not always appear technically correct.
HARDWARE AND PROPRIETARY DESIGN DEPENDENCIES
This is really at the core of the technical challenges. NIST SP-800-90
proposes a neat analytical framework separating digitalization (e.g. an
instrument's firmware) from conditioning (algorithmic processing for
turning noise measurements into fair binary data with an entropy estimate).
Sub-issues: technology obsolescence, calibration and stability of
unpredictable phenomenon digitalization, breakdown of analysis according
to the broad class of unpredictable phenomenon.
DATA / METADATA / ENTROPY ESTIMATE
No matter how fantastic is the true random source, in all cases (with
the exception of the genuine one-time-pad) a deterministic algorithm
crunches the true random data before a security service is provided. The
big picture analysis can not ignore this required mating between true
random source and deterministic algorithms. A deterministic PRNG seeded
by a true random source is usually present in the overall arrangement as
a link in the processing chain.
Before I introduce a definition of entropy, let me stress the separation
of data from meta-data in the processing chain. A simple example of
meta-data is the size of random secret consumption by a run of a given
application. While protections for the data are well-known (secrecy,
statistical properties, reliability, resistance to environmental
influence, ...), security breaches from leakage of meta-data is more subtle.
Entropy is an estimation of information quantity from a data source
derived from a probability distribution
*as*if*the*data*source*could*be*exercised*multiple*times*. It assumes
some stability in the data source properties. Entropy is derived from an
appraisal of the process by which true random data is obtained. I doubt
any automated process can reliably insert entropy estimate in meta-data.
Any arbitrary rule is just a reflection of someone's appraisal.
Nonetheless, as secret random data is processed in the chain of
deterministic algorithms, entropy may be reduced. Given that
deterministic algorithms are implemented with computing efficiency in
mind, opportunities for inadvertently reduced entropy abounds. This is
even more so due to the immaterial aspect of an entropy estimate. It
reminds me the discussions on brute force attacks that are immaterial
nowadays for (symmetric) key sizes above e.g. 256 bits (but they were
immaterial above 112 bits not long ago).
DATA RATE AND ARRANGEMENT OF PROTECTIONS
The data rate of a true random source will remain an order of magnitude
(or more) slower than the processing speed of a system CPU (or dedicated
crypto processor). Bursts of cryptographic operations consuming random
data will force either a PRNG expander of randomness or true random data
buffering, both of which implies system state data that requires secrecy
protection.
(The data rate limitation occurs even with the single photon detector
which seems to be the foundation of so-called quantum random number
generator, because the single photon detector, just like any type of
sensor, requires interfacing and digitilization which occurs at typical
speed of classical electronics.)
In any event, a cryptographic system invariably needs a secure storage
arrangement ("chmod 600 filename" as a very least) for secret or private
key material. I would like to see a publication about the pros and cons
of relying on such secure storage in a secure system design instead of a
higher speed true random source. I suspect overall protections are
enhanced if design/implementation efforts are devoted to secure storage
(where a PRNG state may be kept) and correspondingly lesser emphasis is
put on high speed true random source.
CONCLUSION
Much needs to be done for secure system design principles when the
complete life cycle of true random is considered. In addition, the
immaterialness of entropy estimates is the source of great confusion
among system designers more used to measurable properties.
Comments are welcome!
CAVEAT
Elsewhere with the PUDEC proposal (http://pudec.connotech.com), I make
an argument for a unique arrangement featuring self-evident entropy
estimate but a random source data rate asymptotically close to zero.
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
