On 17/08/13 14:46 PM, Ben Laurie wrote:
On 17 August 2013 06:01, ianG <i...@iang.org <mailto:i...@iang.org>> wrote:
On 17/08/13 10:57 AM, Peter Gutmann wrote:
Nico Williams <n...@cryptonector.com
<mailto: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.
That's terrible advice. Implement your own crypto of any sort widely
leads to complete fail, as we see repeatedly.
:) Perhaps the distinction is that, if you care, when you "repeatedly
fail" then you can repeatedly fix it. OTOH, if you're using external
crypto, you're up the creek without a paddle.
Also, if there are other sources, why are they not being fed in to the
system PRNG?
I agree in principle, but reality slaps us around a bit:
Linux and BSD can't agree on the basic definitions of urandom and
random. Some don't agree whether Intel's RNG is safe or not for Linux
purposes. Zooko & Jon don't agree whether open source is a sufficient /
necessary proof.
And, as you say, FIPS don't agree with anyone:
> Amusing story: FIPS 140 requires self-tests on the PRNG. There was a
> bug in FIPS OpenSSL once where the self-test mode got stuck on and so
> no entropy was fed into the PRNG.
>
> Also, back when I was doing FIPS 140 they made me remove some of the
> entropy feeds into the PRNG - particularly ones that protect against
> pool duplication over forks.
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
