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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of > [EMAIL PROTECTED] > 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" <[EMAIL PROTECTED]> > > > 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: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
