Ivan Jager <[EMAIL PROTECTED]> writes:
> On Wed, 14 May 2008, David Härdeman wrote:
>> If the entropy pool is properly coded, there is no negative effect of
>> adding data which may or may not be truly random to the pool (i.e. you
>> cannot degrade the quality of the pool no matter what you add). Therefore
>> step b) might add some entropy or it might do nothing at all, depending on
>> how truly random the uninitialized data is, but it won't hurt.
>
> I think that might depend on how not truly random the data is. For
> example, suppose the pool is coded to simply xor the new entropy with
> the pool. This works great when the entropy is distributed evenly
> through all the bits. If you treat it as a black box, it may seem that
> no matter what entropy you add, you can't make the pool any
> worse. However, if the entropy you add happens to be a copy of the
> pool...
That would require you to
a) know the contents of the pool
More entropy gets added later so you have to forsee what will be
added.
b) be able to influence what is actually added
The buffer itself isn't actualy added from what I read but
hashed. So you have to device the buffer in such a way that the
hashed valued cancel out the pool contents. You have to break the
hashing function.
> I'm pretty sure openssl uses something better than xor, but I don't
> see how you could code a pool so it wouldn't be possible to degrade
> the quality by adding the right fake entropy.
You use a hash function to make it impossible (actually just verry
hard) to control the pattern actually being added. The hash function
will not destroy entropy (unless it is broken) from the input but
destroys patterns.
>> The goal of the patch that was used in Debian's OpenSSL was to placate
>> valgrind by removing step b) as valgrind complained about the use of
>> uninitialized memory (here it was one of the few cases where it might be
>> legit to do so).
And clearly, since the adding of the memory was the only use of the
memory in that function, the right thing would have been to initialize
the memory or not add it at all. And I mean don't call the function
with an uninitialized buffer in the first palce instead of changing
the function to ignore any buffer given.
Simplified the code comes to this:
void add(char* buf) {
for(i = 0; i < size; i += 20) {
add_buf_to_pool(buf, i);
buf += i;
}
}
'buf' is only ever used to be added to the pool in the function. There
is no other use of it there.
And the patch commented out the 'add_buf_to_pool' call instead of
looking for where 'add' was called with an uninitialized buffer.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
