On 17/08/13 10:57 AM, Peter Gutmann wrote:
Nico Williams <n...@cryptonector.com> writes:
It might be useful to think of what a good API would be.
The problem isn't the API, it's the fact that you've got two mutually
exclusive requirements, the security geeks want the (P)RNG to block until
enough entropy is available, everyone else wants execution to continue without
being blocked. In other words a failure of security is preferred to a failure
of functionality. Until you resolve that conflict, no API (re)design is going
to help you.
(not answering the posts sepcifically but) the rule of thumb I've always
used is this:
If you don't care so much about security then use the tools that are
provided, and suffer an occasional glitch. Don't worry too much about
the glitches coz your business already told you, you don't care too much
about the security / randomness. All those cypherpunkian arguments can
go to hell, you've got customers to care for.
OTOH, if you care a lot, then you have to write your own. The design is
now very well established. Many sources -> mixer/pool -> deterministic
PRNG. It's really not that hard, this is an intern level project, folks.
In result, if you care enough to argue about random v. urandom then you
already put yourself in the second camp, and your problem is solved.
Just use urandom and collect some other sources yourself. You no longer
care.
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
