Without a /dev/random device your not cryptographically
secure. If you fudge it and allow a connection anyway
you are essentially lying to the users - they think it's
secure but it really isn't.

Ted

> -----Original Message-----
> From: owner-openssl-users@openssl.org
> [mailtowner-openssl-users@openssl.org]On Behalf Of
> urjit_gokhale@persistent.co.in
> Sent: Saturday, January 12, 2008 7:58 PM
> To: openssl-users@openssl.org
> Subject: RE: Handling missing random number generator
>
>
>
>
> ---- Original message ----
> >Date: Sat, 12 Jan 2008 03:42:36 -0800
> >From: "Ted Mittelstaedt"

>
> > The easiest way is to have the user install a random
> > device. There's ones out there
> > for Solaris all the way back to version 2.5.1
> >
> > However, keep in mind that all but the latest
> > /dev/random devices out there do
> > not generate very good random numbers, the newer
> > ones use the Yarrow engine,
> > but the very best ones also derive randomness from
> > the hardware random number
> > generators on some of the CPUs (ie: the VIA C3
> > Nehemiah, the Intel 82802
> > ie x810 chipset) or from devices like the following
> > SG100:
> >
> > http://www.protego.se/sg100_en.htm
> >
> > Ted

>
> Ted,
> Thank you very much for your response.
> I will consider that option. But my question is, what if it is
> not present, and for whatever reason the user is not willing to
> add it (or add it immediately). For such situation, I thought of
> taking help of RAND_write_file() and RAND_load_file() function.
> Without these functions, my SSL_connect just doesn't connect. And
> I have tested that these functions do make it possible.
> But then, I wanted to use them only as the last option. So I
> wanted to know how to detect the existence / absence of the
> random number generator, based on which I would call these functions.
>
> Do I just test if any of /dev/urandom, /dev/random or
> /dev/srandom is present? Or is there a better way ?
>
> Really appreciate your help.
>
> ~ Urjit
>
> >
> > -----Original Message-----
> > From: owner-openssl-users@openssl.org
> > [mailtowner-openssl-users@openssl.org]On Behalf
> > Of Urjit Gokhale
> > Sent: Monday, January 07, 2008 1:06 AM
> > To: openssl-users@openssl.org
> > Subject: Handling missing random number generator
> >
> > Hello,
> >
> > I observed that on few platforms, the random
> > device is missing. Due to this, the SSL_connect
> > fails. I would have to use -rand option of
> > s_client for successful connection.
> > On such platforms, even my client application
> > fails due to the missing random number generator
> > device.
> > For eg. On my solaris box, my client fails and
> > truss gives the following output:
> > =============
> > 0.0999 open("/dev/urandom",
> > O_RDONLY|O_NONBLOCK|O_NOCTTY) Err#2 ENOENT
> > 0.1003 open("/dev/random",
> > O_RDONLY|O_NONBLOCK|O_NOCTTY) Err#2 ENOENT
> > 0.1007 open("/dev/srandom",
> > O_RDONLY|O_NONBLOCK|O_NOCTTY) Err#2 ENOENT
> > 0.1013 so_socket(1, 2, 0, "",
> > 1) = 5
> > 0.1018 connect(5, 0xFFBEE3F8, 19,
> > 1) Err#2 ENOENT
> > 0.1021
> > close(5) =
> > 0
> > 0.1025 so_socket(1, 2, 0, "",
> > 1) = 5
> > 0.1029 connect(5, 0xFFBEE3F8, 15,
> > 1) Err#2 ENOENT
> > 0.1032
> > close(5) =
> > 0
> > 0.1035 so_socket(1, 2, 0, "",
> > 1) = 5
> > 0.1039 connect(5, 0xFFBEE3F8, 15,
> > 1) Err#2 ENOENT
> > 0.1041
> > close(5) =
> > 0
> > 0.1046 so_socket(1, 2, 0, "",
> > 1) = 5
> > 0.1050 connect(5, 0xFFBEE3F8, 14,
> > 1) Err#2 ENOENT
> > =============
> > And then the SSL_connect fails with
> > SSL_ERROR_SYSCALL and errno set to 2.
> >
> > In such cases, I had thought of using
> > RAND_write_file() followed by RAND_load_file()
> > just after loading required libraries
> > (SSL_load_error_strings, SSL_library_init).
> >
> > Do you think this is sensible approach? If not,
> > could you suggest ways to deal with situations
> > when the random device is missing?
> > If yes, I have another question. How to detect,
> > programatically if the random device is missing?
> > The RAND_write_file() and RAND_load_file() should
> > be used only if the random device is missing,
> > right?
> >
> > Any help in understanding this is highly
> > appriciated.
> >
> > Thank you,
> > ~ Urjit
> >
> > DISCLAIMER ========== This e-mail may contain
> > privileged and confidential information which is
> > the property of Persistent Systems Ltd. It is
> > intended only for the use of the individual or
> > entity to which it is addressed. If you are not
> > the intended recipient, you are not authorized to
> > read, retain, copy, print, distribute or use this
> > message. If you have received this communication
> > in error, please notify the sender and delete all
> > copies of this message. Persistent Systems Ltd.
> > does not accept any liability for virus infected
> > mails.

>
> DISCLAIMER
> ==========
> This e-mail may contain privileged and confidential information
> which is the property of Persistent Systems Ltd. It is intended
> only for the use of the individual or entity to which it is
> addressed. If you are not the intended recipient, you are not
> authorized to read, retain, copy, print, distribute or use this
> message. If you have received this communication in error, please
> notify the sender and delete all copies of this message.
> Persistent Systems Ltd. does not accept any liability for virus
> infected mails.
> __________________________________________________ ____________________
> OpenSSL Project http://www.openssl.org
> User Support Mailing List openssl-users@openssl.org
> Automated List Manager majordomo@openssl.org
>

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majordomo@openssl.org