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]