travis+ml-cryptogra...@subspacefield.org wrote:
Hey all,
I also wanted to double-check these answers before I included them:
3) Is determinism a good idea?
See Debian OpenSSL fiasco. I have heard Nevada gaming commission
regulations require non-determinism for obvious reasons.
Do those sound right?
I guess the more productive question is "Since determinism requires a
PRNG algorithm of some sort, which PRNG properties are needed in a given
usage context?"
In all cases, the PRNG relies on a "true" random source for seeding.
You refer to IT security clients (SSL fiasco), IT security servers
(virtualization), and lottery/gaming systems. In IT security nowadays
large PRNG periods and crypto-strength PRNG algorithm are the norm. As I
understand the state of the art in lottery/gaming industry (incl.
standards), it is an accepted practice to use "short" period (by IT
security standards) PRNG combined with a form of continuous entropy
collection: background exercise of the PRNG.
I think the SSL fiasco "root cause analysis" would remind us of criteria
that are nowadays well addressed in the IT security sector (assuming
minimal peer review of the design and implementation).
In a security analysis, you watch for data leaks, either in the source
of truly unpredictable events, or the present/past PRNG state for the
deterministic components of your design. If you already need data leak
protection for private or secret keys, your system design may already
have the required protections for the PRNG state (except that the PRNG
state is both long-term -- as a long-term private key or long-term
symmetric authentication key -- and updated in the normal system
operations -- as session keys).
So, there is no simple answer. I guess every designs facing actual
operational demands rely on some determinism because a sudden surge in
secret random data usage is hard to fulfill otherwise.
Forgive me to remind the PUDEC (Practical Use of Dice for Entropy
Collection) which mates well with a server system design using PRNG
determinism after installation (or periodic operator-assisted
maintenance). This project is still active. See
http://www.connotech.com/doc_pudec_descr.html . You may see this as a
bias in my opinions, but I don't see any benefits in misrepresenting
relevant facts and analyzes.
Regards,
--
- Thierry Moreau
CONNOTECH Experts-conseils inc.
9130 Place de Montgolfier
Montreal, QC, Canada H2M 2A1
Tel. +1-514-385-5691
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
