Andrea Weisskopf wrote:

the problem with this new error checking is, that RAND_pseudo_bytes clears a PRNG_NOT_SEEDED error it gets from RAND_bytes. an
application using e.g. SSL_connect has no chance to determine why
SSL_connect failed (no error in the ssl error queue, but an error
occurred due to an un-seeded prng in ssl23_client_hello).
>
wouldn't it be better to replace RAND_pseudo_bytes in s23_clnt.c:ssl23_client_hello (and all other occurrences where for
<=0 is checked) with RAND_bytes? then we have a clear error
indication and it is made clear that we need strong random data (as
rfc2246 also says about random_bytes in the client_hello message).

i just noticed that the same question was asked back in november on the user [0] and dev [1] list, but there was no answer too.

so i try to ask again whether there is a reason why RAND_pseudo_bytes is used instead of RAND_bytes? why not make changes like this?



diff -u s23_clnt.c
--- s23_clnt.c
+++ s23_clnt.c
@@ -256,7 +256,7 @@
                p=s->s3->client_random;
                Time=time(NULL);                        /* Time */
                l2n(Time,p);
-               if (RAND_pseudo_bytes(p,SSL3_RANDOM_SIZE-4) <= 0)
+               if (RAND_bytes(p,SSL3_RANDOM_SIZE-4) <= 0)
                        return -1;

                if (version == TLS1_VERSION)



thanks,
andrea

[0] http://marc.theaimsgroup.com/?l=openssl-users&m=113083681313064&w=2
[1] http://marc.theaimsgroup.com/?l=openssl-dev&m=113049055816831&w=2
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       [email protected]
Automated List Manager                           [EMAIL PROTECTED]

Reply via email to