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 @@
Time=time(NULL); /* Time */
- 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)


__________________________________________________ ____________________
OpenSSL Project
Development Mailing List
Automated List Manager