On Nov 9, 10:53am, Jason wrote:
> Kevin Buettner wrote:
> > The other thing to think about in your client/server application is
> > the communication of your entropy data from the client to the server.
> > If you expose this data in any way (such as sending it in the clear
> > from the client to the server), you've compromised the randomness of
> > the numbers that you wish to later generate since an attacker who has
> > this entropy data will then be able to use this data to predict the
> > numbers that you're generating. (I think it's probably a mistake to
> > try to collect entropy from the clients; if you do, you'll need to be
> > absolutely certain that this entropy is sent securely from client to
> > server.)
>
> Consider, however, if the code is to function in a manner similar to
> PGP... there is no need to protect the public key from interception -
> only a need to ensure that the private key is not readable. As such,
> having the client generate the randomness is in fact the ideal
> solution - and what is needed is not encryption of the public key
> (silly), but rather, a challenge/responce verification scheme to
> ensure that the public key arrives at the server without having been
> tampered with in any form.
I think we're talking about different scenarios. If a client is
collecting entropy (from the keyboard or whatever) for use in it's
own random number generation, that's fine. (But again, you must
take care to protect your source of entropy; the point is that
being localized to the client may make it easier to reasonably
ensure that it's protected.)
If the client programs are sending entropy to a server for the server's
use in generating random numbers, then it *must* be sent securely or
else an attacker could simply collect all the entropy being sent and
use the same algorithm as the server to generate the same numbers.
Kevin
(text/plain)