[13221] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: Randomness

daemon@ATHENA.MIT.EDU (Ben Laurie)
Thu May 8 10:40:06 2003

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 08 May 2003 15:07:58 +0100
From: Ben Laurie <ben@algroup.co.uk>
To: Paul Onions <paul_onions@siliconinfusion.com>
Cc: cryptography@metzdowd.com
In-Reply-To: <E19DNFt-00022d-00@mta03.btfusion.com>

Paul Onions wrote:
> On Monday 05 May 2003 4:51 pm, Ben Laurie wrote:
> 
>>People might be interested in a paper I've written on randomness:
>>http://www.apache-ssl.org/randomness.pdf. Comments, as always, are more
>>than welcome.
>>
>>Cheers,
>>
>>Ben.
> 
> 
> Interesting article, certainly gets one thinking!  One point though.  Quoting 
> from the top of page 6:-
> 
>     Another question is how much state should be shared between the various
>     different APIs. If one assumes the PRNG is secure, then this seems to be
>     easily resolved: they can all share all the state, except insecureprng(),
>     which requires less conditional entropy. Once there is sufficient entropy
>     for the other APIs to start working, then even insecureprng() can share
>     their state.
> 
> Can insecureprng() really share the same state as the secure PRNGs?  Since 
> there is no requirement for unpredictability it would seem that an instance 
> of insecureprng() that leaks the internal state is not disallowed.  So maybe
> it's possible for an adversarial process to reconstruct the internal state 
> from calls to insecureprng(), and then effectively know the answers that will 
> be given to the queries by other processes to the secure PRNGs (or at least 
> acquire enough information to be able to restrict the search for the secure 
> PRNG seeds).

It was my intention, and perhaps I should make it clearer, that the only
difference between insecureprng() and the other PRNGs is the source of
entropy. Hence, it does not leak state any more than the rest do.
Clearly if the insecureprng() uses a cryptographically weak algorithm
then it cannot share state.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com

home help back first fref pref prev next nref lref last post