On Fri, Sep 2, 2011 at 10:37 PM, Jarod Wilson ja...@redhat.com wrote:
Certain security-related certifications and their respective review
bodies have said that they find use of /dev/urandom for certain
functions, such as setting up ssh connections, is acceptable, but if and
only if /dev/urandom can block after a certain threshold of bytes have
been read from it with the entropy pool exhausted. ...
At present, urandom never blocks, even after all entropy has been
exhausted from the entropy input pool. random immediately blocks when
the input pool is exhausted. Some use cases want behavior somewhere in
between these two, where blocking only occurs after some number have
bytes have been read following input pool entropy exhaustion. Its
possible to accomplish this and make it fully user-tunable, by adding a
sysctl to set a max-bytes-after-0-entropy read threshold for urandom. In
the out-of-the-box configuration, urandom behaves as it always has, but
with a threshold value set, we'll block when its been exceeded.
Is it possible to calculate what that threshold should be? The Yarrow
paper includes arguments about the frequency of rekeying required to
keep a block cipher based generator secure. Is there any similar
analysis for the has-based pool? ( If not, should we switch to a
block cipher?)
/dev/urandom should not block unless both it has produced enough
output since the last rekey that it requires a rekey and there is not
enough entropy in the input pool to drive that rekey.
But what is a reasonable value for enough in that sentence?
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
