You should presume your CPRNG output is public (eg published on the web)
What we are talking about in the real world is C_P_RNGs and the C
cryptographic means its suitable for crypto uses, and pseudo means its a
tool for stretching some adequate supply of real entropy (eg 128-bits,
256-bits or whatever) to a whole stream of the stuff suitable for SSL, DSA,
SSH etc, key generation (asymmetric keys).
So IFF the seed is ok, I'd trust FIPS 186-2 annex C (which is based on
HMAC-SHA1) to stretch entropy no problem.
The remaining problems are those identified by the Yarrow authors, and Peter
Gutmann also had a paper on this, which they reference, namely:
a. what if the entropy pool starts empty, and you add new entropy slowly
then maybe if you assume the CPRNG outputs are public, you can brute
force and recover the new CPRNG internal state (seems likely - its just a
hash, if you knew the original, and the entropy is within brute-force
searchable key size realms).
b. and similarly if someone breaks in and grabs a copy of the current
internal state, you want to recover, and for similar reasons if entropy
is added slowly you can brute force the new internal state as in a).
So Yarrow introduced a proposed solution to that being two pools a slow pool
and a fast pool. The idea is the slow pool just accumulates entropy and
less frequently mixes it in. Hopefully in big enough chunks that you cant
brute force from a known start state (ie empty or copied state) to the new
state.
The concept b. grabbing a copy is somewhat bogus because if someone can get
in as root to read your CPRNG state, you have other problems: they can read
your plaintext, backdoor your box, install a root-kit etc.
c. Unattended servers (rackmount in a server room) often dont really have
any decent source of entropy - no keyboard, mouse. Kind of tricky -
maybe should be part of the install process to provide it with some? Or
maybe give it some seed entropy via a secure channel. Or exchange secure
random numbers via SSL, SSH etc with other computers, thereby benefitting
from the combination of randomness on clients which may have keyboards.
And finally a whole new problem is VMs where you have two new problems:
d. if the VM is rolled back or recovered to a snapshot the state can be reset
to an earlier version and repeat earlier CPRNG outputs.
e. there is no real hardware some sources of entropy are in fact bogus, even
though the guest OS maybe doesnt know that.
Solution to d. and e. is to put the CPRNG and entropy gathering in the host
OS.
Adam
On Wed, Jan 26, 2011 at 07:50:51AM -0500, Thierry Moreau wrote:
Peter Gutmann wrote:
Oh, and just to throw a spanner in the works: I've never seen any
standards document or whatever that discusses what to do when you
don't have enough entropy available. There are all sorts of
Rube-Goldberg entropy-estimation methods, but what do you do when
your entropy-estimation says there's not enough available?
Well, you have three choices:
1) block the application processes until some more entropy is available,
2) rely on a
(hopefully-cryptography-strong-devoid-of-implementation-flaws bla bla
bla) PRNG seeded by limited entropy, or
3) fail-safe the system's functions (as if the crypto services were
mission-critical) and expect the end-user to have a hot backup system
in another part of the continent for continuity of operations.
Plus the usual
4) head in the sand attitude: pretend you do 2) but forget about the
parenthesis.
Hint: Halting, i.e. preventing things from continuing isn't an
option.
Unless you hinted towards 4), this reminds me someone who wanted to
have SHA-512 in real-time video capture with a high resolution camera
budget under $300 with forensic-type certification of video
recordings.
Here is a rationale for 2)
unpredictable phenomenon
|
V
digitalization
|
V
conditioning
|
+---> one-time-pad encryption
|
+-------------> application deterministic processing
|
+---> PRNG ---> application deterministic processing
Since you are deemed to be critically dependent on (long term) secret
protection in the application deterministic processing, you may as
well apply secret protection mechanisms to the PRNG state, and enjoy
the "peace of mind" (modulo above bla bla bla) provided by a "good"
PRNG design.
--
- Thierry Moreau
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
