[Cryptech Tech] trng ready for play
Joachim Strömbergson
joachim at secworks.se
Mon Oct 6 19:28:23 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Aloha!
Fredrik Thulin wrote:
> If the above is correct, I have to ask why you need a timeout on the
> fetching of data from entropy providers? Why not just say that the
> mixer requests N bits from all the providers and either they have N
> bits in their buffers or they don't.
Yes, your description is basically correct. But the reason why you need
the ability to timeout is that:
(1) We are using strict round robin access from the entropy providers.
We don't move from one provider to the next unless we have gotten data
from the previous (or a timeout).
(2) You don't know how often and when a reseed operation will occur and
thus when an entropy provider must provide data.
If we take the avalanche based entropy provider it can provide entropy
at a rate of a few kbps. The rosc based entropy provider can provide
data in hundred of kbps up to low Mbps. If we want to a few reseeds in a
second, the avalanche based entropy provider will not be able to keep up
even if we add a fifo that can provide a lot of data.
We can lessen this situation by adding a fifo. But must always be able
to handle the situation that a given entropy provider can not deliver
data when the mixer needs it, and thus the mixer has to wait (because of
(1)). The question is how long it should wait. And if the mixer can wait
indefinitely, there is a problem that the mixer actually livelocks if
the entropy source has b0rked and the entropy provider therefore will
never be able to provide the data the mixer waits for.
> The mixer then has to handle the case where it didn't get the
> requested number of bits back from all sources, but it won't have to
> handle timeouts. I think this would be less complex.
What do you suggest that the mixer should do if it doesn't get the
requested amount of data?
The way it works today, we need in total 2 kbit of entropy data to do a
complete reseed so it is not a lot we need. But the real life problem of
livelock still wont go away.
- --
Med vänlig hälsning, Yours
Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
Joachim Strömbergson Secworks AB joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQIcBAEBCAAGBQJUMu1WAAoJEF3cfFQkIuyN03MQAKcONiqk7OUplqppDfxwlV5b
rt24N5E5asYxu8C8mR96/wXRr/hX0vNKkmalkl2QT6TZVoCSJCKCbJgd2bqWRbEN
S4pgA6q/DeFQ+hgYsV0MOKJaewcuf2botywjFUB66AJRf43hfQY+IKvXY7fdWHCR
kbEnIhbmBkZB8AVxay580JU9Dpf9K5eaClnWI4uh/ylqwbVD2LgBLlLZXdhjiXKr
f483+dikaV13PvhLejYJxVSW72NKySz2eL4Gj1IN2qqNZiS+WqU0khgAlSn0Y2uI
QFHADZs6l4lNObhV8cEMLXo4lNpX4q0b0oVN91Z1yg5F7nLGI8TbOiUrCzNy8Fcn
6AHUz0sHd7/WK8aY5Bdl3uE4adpIIa7H+fhhBxos1sBuYCcALqiHlHh3lwYhvuiZ
vN4xNSTE+87MxZqmWblpp0+l7p8kbYma5PzF6Re+P28KusyveLEDTAXAhcpopMK9
8Yk1rjNQboXga+CwkuROQTx8u2xN0E9guAhPswj8aRAVupUptUkW0UfhJ4CEG4NG
GoKtFqd+X22L9AC8hfYFJkvW72qQyr4mfo9Ftrw/SjBaAgRuacJ8aypEcXokubmN
C3gdGaD3fucuNl2OUQ75CfiKs+Etd1/sE6uW9HPtHRkie/4K3YlMOFvYAPOC0ufz
lgkH8kD2GBPxOCRYiWj0
=tEh1
-----END PGP SIGNATURE-----
More information about the Tech
mailing list