* What is special about OpenSSL on Redhat?
* Why does the OpenSSL compilation fail on MacOS X?
* Why does the OpenSSL test suite fail on MacOS X?
-* Why does the OpenSSL test suite fail in BN_sqr test?
+* Why does the OpenSSL test suite fail in BN_sqr test [on a 64-bit platform]?
+* Why does OpenBSD-i386 build fail on des-586.s with "Unimplemented segment type"?
[PROG] Questions about programming with OpenSSL
* Which is the current version of OpenSSL?
The current version is available from <URL: http://www.openssl.org>.
-OpenSSL 0.9.6h was released on December 5, 2002.
+OpenSSL 0.9.7c was released on September 30, 2003.
In addition to the current stable release, you can also access daily
snapshots of the OpenSSL development version at <URL:
* Where can I get a compiled version of OpenSSL?
+You can finder pointers to binary distributions in
+http://www.openssl.org/related/binaries.html .
+
Some applications that use OpenSSL are distributed in binary form.
When using such an application, you don't need to install OpenSSL
yourself; the application will include the required parts (e.g. DLLs).
-If you want to install OpenSSL on a Windows system and you don't have
+If you want to build OpenSSL on a Windows system and you don't have
a C compiler, read the "Mingw32" section of INSTALL.W32 for information
on how to obtain and install the free GNU C compiler.
Cryptographic software needs a source of unpredictable data to work
correctly. Many open source operating systems provide a "randomness
-device" that serves this purpose. On other systems, applications have
-to call the RAND_add() or RAND_seed() function with appropriate data
-before generating keys or performing public key encryption.
-(These functions initialize the pseudo-random number generator, PRNG.)
-
-Some broken applications do not do this. As of version 0.9.5, the
-OpenSSL functions that need randomness report an error if the random
-number generator has not been seeded with at least 128 bits of
-randomness. If this error occurs, please contact the author of the
-application you are using. It is likely that it never worked
-correctly. OpenSSL 0.9.5 and later make the error visible by refusing
-to perform potentially insecure encryption.
+device" (/dev/urandom or /dev/random) that serves this purpose.
+All OpenSSL versions try to use /dev/urandom by default; starting with
+version 0.9.7, OpenSSL also tries /dev/random if /dev/urandom is not
+available.
+
+On other systems, applications have to call the RAND_add() or
+RAND_seed() function with appropriate data before generating keys or
+performing public key encryption. (These functions initialize the
+pseudo-random number generator, PRNG.) Some broken applications do
+not do this. As of version 0.9.5, the OpenSSL functions that need
+randomness report an error if the random number generator has not been
+seeded with at least 128 bits of randomness. If this error occurs and
+is not discussed in the documentation of the application you are
+using, please contact the author of that application; it is likely
+that it never worked correctly. OpenSSL 0.9.5 and later make the
+error visible by refusing to perform potentially insecure encryption.
+
+If you are using Solaris 8, you can add /dev/urandom and /dev/random
+devices by installing patch 112438 (Sparc) or 112439 (x86), which are
+available via the Patchfinder at <URL: http://sunsolve.sun.com>
+(Solaris 9 includes these devices by default). For /dev/random support
+for earlier Solaris versions, see Sun's statement at
+<URL: http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsrdb/27606&zone_32=SUNWski>
+(the SUNWski package is available in patch 105710).
On systems without /dev/urandom and /dev/random, it is a good idea to
use the Entropy Gathering Demon (EGD); see the RAND_egd() manpage for
provide their own configuration options to specify the entropy source,
please check out the documentation coming the with application.
-For Solaris 2.6, Tim Nibbe <tnibbe@sprint.net> and others have suggested
-installing the SUNski package from Sun patch 105710-01 (Sparc) which
-adds a /dev/random device and make sure it gets used, usually through
-$RANDFILE. There are probably similar patches for the other Solaris
-versions. An official statement from Sun with respect to /dev/random
-support can be found at
- http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsrdb/27606&zone_32=SUNWski
-However, be warned that /dev/random is usually a blocking device, which
-may have some effects on OpenSSL.
-A third party /dev/random solution for Solaris is available at
- http://www.cosy.sbg.ac.at/~andi/
-
* Why do I get an "unable to write 'random state'" error message?
Sometimes, you may get reports from VC++ command line (cl) that it
can't find standard include files like stdio.h and other weirdnesses.
One possible cause is that the environment isn't correctly set up.
-To solve that problem, one should run VCVARS32.BAT which is found in
-the 'bin' subdirectory of the VC++ installation directory (somewhere
-under 'Program Files'). This needs to be done prior to running NMAKE,
-and the changes are only valid for the current DOS session.
+To solve that problem for VC++ versions up to 6, one should run
+VCVARS32.BAT which is found in the 'bin' subdirectory of the VC++
+installation directory (somewhere under 'Program Files'). For VC++
+version 7 (and up?), which is also called VS.NET, the file is called
+VSVARS32.BAT instead.
+This needs to be done prior to running NMAKE, and the changes are only
+valid for the current DOS session.
* What is special about OpenSSL on Redhat?
Look in the file PROBLEMS for a more detailed explanation and for possible
solutions.
-* Why does the OpenSSL test suite fail in BN_sqr test?
+* Why does the OpenSSL test suite fail in BN_sqr test [on a 64-bit platform]?
Failure in BN_sqr test is most likely caused by a failure to configure the
-toolkit for current platform. Run ./config -t and ./apps/openssl version -p.
-Do these platform identifiers match? If they don't, then you most likely
-failed to run ./config and you're hereby advised to do so before filing a
-bug report. If it's ./config itself that fails to run, the it's most
-likely problem with your local environment and you should turn to your
-system administrator (or similar).
+toolkit for current platform or lack of support for the platform in question.
+Run './config -t' and './apps/openssl version -p'. Do these platform
+identifiers match? If they don't, then you most likely failed to run
+./config and you're hereby advised to do so before filing a bug report.
+If ./config itself fails to run, then it's most likely problem with your
+local environment and you should turn to your system administrator (or
+similar). If identifiers match (and/or no alternative identifier is
+suggested by ./config script), then the platform is unsupported. There might
+or might not be a workaround. Most notably on SPARC64 platforms with GNU
+C compiler you should be able to produce a working build by running
+'./config -m32'. I understand that -m32 might not be what you want/need,
+but the build should be operational. For further details turn to
+<openssl-dev@openssl.org>.
+
+* Why does OpenBSD-i386 build fail on des-586.s with "Unimplemented segment type"?
+
+As of 0.9.7 assembler routines were overhauled for position independence
+of the machine code, which is essential for shared library support. For
+some reason OpenBSD is equipped with an out-of-date GNU assembler which
+finds the new code offensive. To work around the problem, configure with
+no-asm (and sacrifice a great deal of performance) or patch your assembler
+according to <URL: http://www.openssl.org/~appro/gas-1.92.3.OpenBSD.patch>.
+For your convenience a pre-compiled replacement binary is provided at
+<URL: http://www.openssl.org/~appro/gas-1.92.3.static.aout.bin>.
+Reportedly elder *BSD a.out platforms also suffer from this problem and
+remedy should be same. Provided binary is statically linked and should be
+working across wider range of *BSD branches, not just OpenBSD.
[PROG] ========================================================================
* How do I read or write a DER encoded buffer using the ASN1 functions?
You have two options. You can either use a memory BIO in conjunction
-with the i2d_XXX_bio() or d2i_XXX_bio() functions or you can use the
-i2d_XXX(), d2i_XXX() functions directly. Since these are often the
+with the i2d_*_bio() or d2i_*_bio() functions or you can use the
+i2d_*(), d2i_*() functions directly. Since these are often the
cause of grief here are some code fragments using PKCS7 as an example:
-unsigned char *buf, *p;
-int len;
+ unsigned char *buf, *p;
+ int len;
-len = i2d_PKCS7(p7, NULL);
-buf = OPENSSL_malloc(len); /* or Malloc, error checking omitted */
-p = buf;
-i2d_PKCS7(p7, &p);
+ len = i2d_PKCS7(p7, NULL);
+ buf = OPENSSL_malloc(len); /* or Malloc, error checking omitted */
+ p = buf;
+ i2d_PKCS7(p7, &p);
At this point buf contains the len bytes of the DER encoding of
p7.
The opposite assumes we already have len bytes in buf:
-unsigned char *p;
-p = buf;
-p7 = d2i_PKCS7(NULL, &p, len);
+ unsigned char *p;
+ p = buf;
+ p7 = d2i_PKCS7(NULL, &p, len);
At this point p7 contains a valid PKCS7 structure of NULL if an error
occurred. If an error occurred ERR_print_errors(bio) should give more
the OpenSSH configure script. It should contain the detailed information
on why the OpenSSL library was not detected or considered incompatible.
+
* Can I use OpenSSL's SSL library with non-blocking I/O?
Yes; make sure to read the SSL_get_error(3) manual page!