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
