<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>What I can do is to forward your concerns to the Botan mailing list. To discuss the usage of "ls -alni /tmp" as one of the low priority sources.</div>
<div></div></div></div></div></blockquote></div><br></div><div class="gmail_extra">Here is the response from Jack Lloyd:</div><div class="gmail_extra"><p class="">Well, there are two issues potentially involved - that a
local attacker can manipulate the input, and that a local attacker can see
/tmp.</p>

<p class="">With regards to input manipulation - the PRNG design is
explicitly intended to process arbitrary attacker chosen inputs; as long as the
min-entropy of the entire set of sampled data is sufficiently high, there
should not be a problem. There is substantial justification for this in the
paper on which the RNG is designed (<a href="http://webee.technion.ac.il/~hugo/kdf/kdf.pdf">http://webee.technion.ac.il/~hugo/kdf/kdf.pdf</a>).
It is worth considering that a local attacker can also manipulate inputs via
other approaches (process names in ps output, filenames in lsof and netstat
output, etc).</p>

<p class="">However in terms of entropy provided, keep in mind that
for a local attacker, Unix_EntropySource provides very little conditional
entropy anyway, as the entire point of it is that it is querying information
which is publically available to users of the local machine, and a local attacker
could easily sample the same set of sources. So the entropy gathered
(conditioned on the attackers knowledge of what he sampled, potentially at a
high resolution) would be quite small in any case.</p>

<p class="">The problem of gathering large amounts of entropy on a
system without a kernel provided/protected PRNG and a local attacker is not a
satisfactorily solved one to my knowledge. There is simply not that much
variability to sample from in that situation; the only approach I'm aware of
that might work is timing jitter ala truerand, which essentially is trying to
sample from the hidden states of clocks (drifting characteristics) and the
scheduler. I've done experiments with some approaches along this line in the
past, but not nearly enough to convince myself that it can be done in a way
that behaves securely, especially across a range of hardware and kernels.</p>

<p class="">All that said, I am not particularly tied to ls /tmp as a
source so if for whatever reason this particular one is of great concern to
your users it can be removed without issue, but I hope I've made it clear how
that is a very small part of a larger issue surrounding entropy collection.
Also, if earlier polls (eg /dev/random or EGD) succeed, then we will never
query these sources at all, as spawning off all these processes is quite slow,
so we avoid it except in cases where it is necessary due to lack of other
options.</p>

<span style="font-size:11pt;font-family:Calibri,sans-serif">Hope this makes sense, let me know if you have any
other questions.</span><br></div></div>