Hi!
I am currently in a discussion with Bill Browning about entropy gathering
and as suggested I would like to share the discussion with the forum both
for others to be informed and to get more input on it.
Best regards,
Lutz
----- Forwarded message from Lutz Jaenicke <[EMAIL PROTECTED]> -----
Date: Wed, 24 Jan 2001 11:10:31 +0100
From: Lutz Jaenicke <[EMAIL PROTECTED]>
To: Bill Browning <[EMAIL PROTECTED]>
Subject: Re: Gathering Entropy quickly for openSSL
User-Agent: Mutt/1.2.5i
In-Reply-To: <[EMAIL PROTECTED]>; from
[EMAIL PROTECTED] on Tue, Jan 23, 2001 at 04:32:21PM -0800
Organization: BTU Cottbus, Allgemeine Elektrotechnik
On Tue, Jan 23, 2001 at 04:32:21PM -0800, Bill Browning wrote:
> I have a couple of questions regarding continuous entropy gathering
> in situations where processor time is limited. I've had a look at
> PRNGd-0.9.1 I am glad that you have taken an approach similar to my own for
> seeding the PRNG in openSSL. My initial version does the following every
> time one of my SSL objects is created:
> df -a
> mpstat
> ps -fed
> I'm considering adding several other commands as contributed by Louis
> LeBlanc to your own project. This brings me to my first question, how did
> Mr. LeBlanc or yourself calculate the usable bits of entropy per byte of
> data? Are these based on "rule of thumb" or something more concrete?
No, it is just the "rule of thumb" being applied. There are some "estimates"
in different sources but finally it is just guessing. If you call "df -a"
how many "unexpected/unpredictable" bits do you get? How many do you get if
you call 'df -a' 10 times in a row. At least the answer to the last question
is not so difficult: you get as much as you get from the first call. When
you can guess the first output of 'df -a' you also know the other 9 results...
Several of the entropy estimates I have seen are coming from cryptographic
analysis of texts. If you want to break a cipher it helps to know statistic
properties of a typical text and as far as I remember a typical text has
an entropy of approximately 10%. (Different languages may yield different
results, but e.g. english comes down to short words with " " in between,
the words "of", "a", "the" are used very often etc...)
To wrap up a long statement: it is just rule of thumb, I have copied over
the config-file format and estimates from the OpenSSH package.
> Since I am involved in using openSSL to transport a protocol
> designed within my company I have the luxury of changing the way the
> protocol behaves. I am planning to change it so that the following occurs:
> 1. Client seeds its random number generator via the screen pixels
> (via RAND_screen( ) )
> 2. Client completes an SSL connection to the server.
> 3. Client passes a 32 bytes random sequence to the server (generated
> via RAND_bytes( ) )
> 4. Server adds this seed data (via RAND_seed( ) )
Depending on the cipher used, the client will need entropy in any case, the
server might already need entropy to establish the connection.
(For e.g. RC4-MD5 the client needs entropy, the server does not. This comes
down to the result, that you can decrypt a recorded RC4-MD5 connection when
getting access to the private key. (-> ssldump) (EXP-RC4-MD5 needs a
temporary 512bit RSA key, so random numbers are required.)
For DH ciphers both client and server generate a random key, so this is not
possible...)
> The reason I wish to do this stems from the fact that my server runs on both
> Unix and Windows platforms and I would like a platform independent way of
> improving the entropy as time goes on.
>
> My questions regarding this procedure are:
> 1. By passing 32 bytes of random data at the beginning of each SSL connect
> (after handshake is completed of course!) am I likely to have weakened the
> cryptographic strength of any the algorithms available in ssl? (excluding
> IDEA which I do not have license to use)
- When the connection would be decrypted (see above), an attacker would get
access to the random bytes retrieved from your PRNG. This might reveal
additional state information about your PRNG to allow guessing of the state.
So you should make sure that the seeding (in which way ever you are going
to estimate it) should be large enough to create the secret for the
new connection (16bytes minimum for an 128bit symmetric key) and the
32bytes to be transferred. So you should have more than 48bytes of entropy
in the PRNG. In order for this problem to apply, somebody must already
be able to decrypt your connection _or_ have subverted the server...
- On the other hand, by sending the random bytes you make a "plain text
attack" more difficult, as the plain text sent is random. (This is different
e.g. for HTTP, where the data sent is a HTTP query the structure of which
is pretty well known).
> 2. In order for someone to mount an attack on the PRNG (assuming that they
> already have perfect information about sampled data on the server) they
> would need to be able to control/predict the seeding of the PRNG on each
> client, correct?
Yes, provided that they only have normal user permission on the server.
If they have superuser permission they might find a way to manipulate the
software on the server side, they might also get access to the "clear text"
of the entropy data sent, hence maintain there knowledge about the state.
(That's why PRNGD uses stat() calls for entropy gathering taking into account
size and access dates. You cannot watch them without having an "strace"
monitoring the system calls and for doing this you must have superuser
permission (in which case I consider to have far more severe problems).
> 3. Does this actually improve the entropy of the PRNG significantly? How
> would I calculate the bits of entropy per byte for this?
Yes, it would improve the entropy (32bytes is equivalent to one 256bit
symmetric key or two 128bit symmetric keys). For the calculation the
protocol is important. You have to consider the case of a manipulated
client, where somebody will send you "well known" random bytes, in which
case they account for "0".
> Thanks for your time in this.
I also learn from these discussions.
> Please feel free to post this message and your reply to openSSL-users if you
> feel that others could benefit from this information.
That is probably a good idea, we might get more input on the discussion.
Best regards,
Lutz
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
----- End forwarded message -----
--
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus Fax. +49 355 69-4153
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
