> > If feeding predictable data into a PRNG that was already well > > seeded with > > unpredictable data produced a weaker PRNG, then you have found > > a security bug > > in the PRNG and I suggest you publish.
> Yeah, I've heard that a few times. However, consider the > pathological case, > in which an adversary manages to introduce N-1 bits of known > state into your > PRNG which has N bits of internal state. Are you comfortable > with that? Yes. > For > what value M are you comfortable with N - M bits of the state having been > introduced by the adversary? Why? An attacker can feed an infinite amount of known entropy into the pool. The result is that it has as much entropy as it had before he did that. > It seems to me that best practice is to not introduce such state if one > can avoid it, whether one counts it into an entropy estimate or not. Why? Because it's always possible that the algorithm actually has some unknown defect that might make this bad? What if the algorithm has some unknown defect that doing this fixes? The entropy pool is specifically designed, as a major security objective, such that: 1) An attacker can remove an unlimited amount of entropy from the pool and it is still computationally infeasible to know anything about the next byte that will come out, and 2) An attacker can add an unlimited amount of known "entropy" to the pool and it is still computationally infeasible to know anything abou the next byte that will come, and 3) An attacker can do both 2 and 3 in any amount in any computation, and the pool is still just as secure as it was before he did so. These are not accidents. These are the specific design criteria for the entropy pool PRNG used and its design specifically reflects these objectives. If you have any reason or evidence to suspect that any of these is not true, please share it. Otherwise, you're just asking us to hope that the hypothetical attack this might somehow make us less vulnerable to is more significant to the hypothetical attack this might somehow make us more vulnerable too. And that would just be your guess. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
